Banco de dados - Principais erros no desenvolvimento de software

Hoje vamos tratar de um assunto pouco levado em conta por empresas desenvolvedoras de softwares sem competência profissional para desenvolver software com banco de dados.

Origem do problema e soluções

É comum o empresário não enxergar a importância do banco de dados sobre como este deve ser implementado e os impactos futuros em seus investimentos. Se você é este empresário, o problema pode ser resolvido através de três alternativas bases:

1. contratar um profissional especialista a partir de critérios de seleção adequados para identificar um especialista comprometido e focado. Este especialista deve conhecer de modelagens de bancos de dados relacionais, multidimensionais e não relacionais com experiência comprovada no exercício de seus trabalhos em projetos de variada complexidade e finalidade. Sua formação deve ser comprovada no campo teórico e prático, para isso, é importante compreender se o especialista tem experiência nos bancos de dados predominantes no mercado, não é recomendável contratá-lo somente baseado na tecnologia do banco de dados utilizado por sua empresa;
2. se sua empresa não tem demanda o suficiente para contratar um especialista, então procure ponderar as características de um especialista em banco de dados para uma das competências de um analista de seu quadro profissional, é possível identificar no mercado profissionais focados em análise de projetos com excelente competência desenvolvida profissionalmente e academicamente em banco de dados;
3. a outra maneira de sanar o problema é identificar em sua equipe de projetistas um profissional alinhado com banco de dados e então investir em cursos de boa procedência e até mesmo adicionar na atividade do profissional o aprendizado formal sobre o assunto, mas neste caso, não transfira a responsabilidade do pagamento do curso ou compra de livros para o profissional porque isso é má fé, e o profissional mais cedo ou mais tarde pode perder sua motivação ao se sentir lesado.

Mitos e verdades acadêmicas

No final de 1990, ocorreu uma crescente busca pela Análise Orientada à Objetos (A.O.O.), pois a sua antecessora, a Análise Essencial (A.E.) já não sustentava as demandas por projetos de sistemas porque seus documentos não eram de fácil compreensão para os menos envolvidos no projeto do sistema e principalmente, o cliente final, mesmo sendo estes do campo da ciência ou tecnologia.

Nota: Embora a Análise Essencial não comunicasse claramente com todos os envolvidos, é importante resgatar, ela simplificou em muito as técnicas de desenvolvimento de softwares, pois tratava de amparar a projeção de um software detalhadamente sem considerar a forma de implementação, desta maneira a Análise Essencial tinha como principais contribuições o foco no serviço a ser entregue ao cliente e melhor controle das estruturas (funções), porém, numa visão de quem implementa o projeto.

A Análise Essencial evoluiu da Análise Estruturada, esta é praticamente o primórdio da análise para projeto e desenvolvimento de sistemas ao alcance de pessoas comuns, sem dotes de gênios, e a maior parte da compreensão da maneira de conceber um novo sistema ainda é um legado dessa análise. A Análise Estruturada se pauta na seguinte ordem elementar para projetar um sistema: DFD (Definição Fluxo de Dados), DER (Definição de Entidade-Relacionamento) e MER (Modelo de Entidade-Relacionamento). O DFD é o estudo lógico dos dados de entradas, processamentos e dados de resultados após os processamentos. Após elucidada esta etapa, o analista partia para a definição das entidades do sistema e seus relacionamentos. Já ao final destas etapas, o especialista em banco de dados cuidava de tratar do modelo de armazenamento dos dados a considerar o melhor desempenho, menor consumo de recursos computacionais e a fácil manutenção.

De volta a crescente busca pela Análise Orientada à Objetos, nas escolas e nas empresas, tornou-se um modismo dar total ênfase a A.O.O. porque ela comunicava bem com o cliente final a partir dos documentos exigidos por essa análise, mas toda contribuição das suas análises antecessoras foram subestimadas radicalmente e passamos a ver excelentes diagramas lógicos com uma clareza quanto o seu fluxo de processamento do sistema, identificação dos objetos operados pelo sistema e quase todos os estados possíveis de um processamento eram elucidados de maneira bastante simples. O principal estopim do sucesso da A.O.O. foram os esforços no início por parte das empresas em entregarem diagramas mais claros para os seus clientes validarem seus pedidos e terem real capacidade crítica a respeito do proposto sistema.

Assim como dizem que a arte imita a vida, a programação imita a análise. Quer dizer,  na última década, emergiram ferramentas de alta produtividade e estas ferramentas privadas ou desenvolvidas por comunidades de códigos livres, passaram a potencializar a Orientação à Objetos, mas uma nova anomalia surgiu no mercado de desenvolvimento, os Objetos da Programação Orientada à Objetos (P.O.O.) passaram a ser confundidos com as Entidades do Modelo Entidade-Relacionamento. Aqui é importante destacar, os Objetos são estruturas geradas durante o ciclo de vida de um sistema com uma conotação dos objetos do mundo real para facilitar ao programador não perder o foco no serviço esperado. Quando o sistema se encerra, os Objetos normalmente precisam ser armazenados em banco de dados. Já as Entidades não tem relação direta com os Objetos, pois Entidades estão relacionadas a forma de armazenar os resultados de uma operação do sistema, seja esta um cadastro ou uma transação financeira por exemplo.

Normalmente os profissionais de TI possuem este discernimento teórico, mas na prática, as demandas os exigem e os encantaram demais a concentrarem suas cresças em apenas a A.O.O. e a P.O.O.. O problema deste deslocamento de conhecimento para apenas uma geração de análise é deixar para trás técnicas de conhecimentos importantes para o suprimento de falhas da A.O.O..

Agora temos no mercado um excesso de programadores sendo responsabilizados pelo modelo do banco de dados sem o devido conhecimento. Este problema é agravado porque na entrega do sistema, o banco de dados está vazio e as omissões ou banalizações do Modelo Entidade-Relacionamento, só passam a apresentar seus efeitos quando o banco de dados cresce e atinge um grande volume de dados.

Nesta etapa, os contratos já foram concluídos e o cliente passa a arcar com o ônus das omissões de uma geração cobrada apenas para produzir dentro da última moda do campo da análise e não podem pensar demais porque é um geração pressionada por resultados para cumprir pequenos prazos, realizarem custos baixos e entregar uma falsa qualidade.

O cliente também é corresponsável por isso quando pressiona seu fornecedor de software a menores prazos e preços todavia.

Concluí-se portanto este problema sendo mais mercadológico do que de uma parte ou de outra. Projeto de software ainda é visto por muitos como algo simples e rápido, qualquer pessoa consciente ao tentar dizer o contrário sofrerá retaliações, não pessoal, mas é porque projeto de software é commodity pelo volume de ofertas atual.

Principais erros no desenvolvimento de software com banco de dados

Vamos a verificação dos principais erros, alvos deste artigo.

1) Confundir Objeto com Entidade

A confusão do Objeto com a Entidade é um erro normalmente ocorrido na etapa de concepção de um sistema, pois pensa-se no Objeto como sendo um tabela nos casos mais crônicos.

2) Não se releva no projeto de software a importância do MER

A falta de competência em Modelo Entidade-Relacionamento está ligado ao mal investimento de uma empresa fabricante de software, porque pensa-se no hoje somente, a lógica do consumo rápido faz todos esquecerem dos efeitos desta omissão. Na prática, o banco de dados é um sistema e como qualquer sistema, tem seus pré-requisitos para funcionar corretamente, manter o desempenho ao longo de seu crescimento, atender as necessidades de relatórios sem impactar o sistema que o abastece, conhecido como sistema operacional (não tem nada a ver com Windows, Linux e outros, trata-se do sistema com as operações desenvolvidas e ligado ao banco de dados).

A presença do profissional especialista em banco de dados ainda é a melhor maneira de projetar um sistema capaz de manter o mesmo desempenho em seus primeiros dias de vida e após meses de funcionamento porque ele vai saber como organizar os dados em entidades, gerar os relacionamentos, identificar as indexações vitais para o desempenho das operações principais, relatórios, determinará as políticas de manutenção dos dados como é o caso do controle transacional quando muitas entidades estão envolvidas em uma operação, escalonamento para o sistema comportar novos módulos ou funcionalidades sem sofrer deformações impactantes para o sistema operacional e muito mais.

Em resumo, somente um profissional competente é capaz de prever com muito mais facilidade do que um programador as melhores práticas de organização e manutenção dos dados operacionais e ainda saberá resolver as novas demandas por processamentos gerenciais sobre o banco de dados sem impactar o sistema principal.

3) Erros principais em relatórios

Não é anormal se você for investigar seus relatórios, identificar problemas críticos que impactam na integridade das informações esperadas por você e você nem saber destes problemas. Aqui falo do programador pressionado a gerar relatório, dentro do seu conhecimento ele tende a ignorar as normas de relacionamentos, filtros constantes e variáveis a serem aplicadas na consulta do relatório. Na prática ele pode, por exemplo, apresentar os resultados financeiros parcialmente porque fez uma relação "inner join" (deve estar contido nos dois conjuntos para mostrar a informação) entre a tabela de resultados com cadastros. Se o cadastro for facultativo, simplesmente as transações ocorridas para o cadastro não realizado não serão mostradas e é comum este erro, somente os usuários mais críticos conseguem perceber o problema mesmo sem entender a causa e reclamar a empresa fabricante do software.

Outro problema é a maneira de construir a consulta do relatório, pois o programador desconhece na maior parte das vezes as corretas práticas para interagir com um banco de dados, por isso ele costumeiramente ignora a necessidade de criar índices adequados a consulta ou quando cria os índices, não possui propriedade para criar o índice dentro da ordem necessária requerida pelo banco de dados oferecer o real bom desempenho. Um índice criado com falha ou desnecessário, pode repercutir em lentidão nas operações principais de um sistema.

Por fim, quando um programador receber a responsabilidade de modelar o banco, por coerção na visão geral do mercado, normalmente ele desconhece o que é entidade forte, entidade fraca, relacionamentos, chaves primárias, chaves estrangeiras, cardinalidade, espécies de índices e por isso, pode arbitrar durante a construção de uma consulta e violar muitos dos pré-requisitos de um banco de dados. O impacto disso? Relatórios simples graficamente, porém demorados, são sem integridade ou impossíveis de serem executados a partir do aumento do volume de dados.

4) Computação financeira ou contábil

Normalmente este erro vem do erro de relacionar pessoas que trabalham com computador, pessoas que dominam a matemática financeira ou contábil.

Dificilmente se vê um processamento deste detalhado claramente em um documento, pois o programador receber toda a responsabilidade em atender esta demanda computacional sem que este trabalho seja previamente especificado ou posteriormente conferido com o rigor necessário.

O impacto neste caso depende de quem utiliza os dados computados para fins financeiros ou contábeis. Caso a informação esteja incorreta, o cliente pode pagar alguma tributação para mais ou para menos porque mal saberá se existe falha porque o cliente geralmente confia em seus sistemas.

Conclusão

O problema abordado aqui está relacionado de fato a banalização do MER pelas empresas desenvolvedoras.

A saída do problema depende de cada empresa fabricante de software impor condições melhores para a entrega de um produto, mesmo se para isso ela tiver que abrir mão de novos atendimentos, pois estes na verdade estão ligados a retrabalho e não a desenvolvimento.