28 SQL Magazine - Mantendo as regras de negócios no banco de dados: os prós e os contras

Mantendo as regras de negócios no banco de dados: os prós e os contras

Paulo Sergio Pereira (psergio.p@terra.com.br)

É desenvolvedor (Java , Visual Basic, .NET, 4GL, ADVPL e Webspeed) e administrador de bancos de dados Progress, SQL Server 2000/2005 e DB2. É Bacharel em Ciência da Computação pela Uni-vap - Universidade do Vale do Paraíba. Atua como consultor pela empresa Compasso em projetos Visual Basic e Java com banco de dados Oracle.

[ Banco de Dados ]

Todo sistema empresarial tem como principal função assegu-rar que as regras de negócios da

empresa sejam obedecidas, garantindo a consistência das informações e forne-cendo dados importantes aos gestores que podem ser usados em tomadas de decisões. Portanto, a qualidade e confiabilidade das informações mani-puladas devem ser fator primordial nos sistemas empresariais. Neste artigo veremos os casos em que é interessan-te manter estas regras de negócios no banco de dados e os casos em que essa prática se torna inviável.

O que são regras de negóciosAs regras de negócios determinam

como uma empresa funciona, o que dever ser feito e como deve ser feito. As regras de negócios variam de empresa para empresa, porém, empresas do mesmo ramo de atividade normalmente têm regras de negócios semelhantes. A definição para regras de negócios é

a seguinte: “São declarações que apre-sentam a maneira como o negócio está sendo feito, além das diretrizes e restri-ções com respeito a estados e processos em uma determinada organização”. As regras de negócios normalmente podem ser classificadas em dois tipos:

• Regras de integridade: representam a semântica das restrições de integri-dade. Neste caso, uma regra foi violada e uma condição de erro deve obrigato-riamente ser disparada. Um exemplo seria uma regra onde o estoque de um produto não poderia ficar negativo. Se alguma operação levar a esta condição um erro deve ser lançado e a operação deve ser cancelada;

• Regras de automatização: neste caso não existe violação de regra, apenas uma situação onde uma tarefa deve ser dispa-rada automaticamente, ou seja, sem inter-venção do usuário. Um exemplo seria uma condição onde novos pedidos devem ser incluídos para um produto caso seu esto-que chegue a uma quantidade mínima.

SQL55.indb 28 04.07.08 11:29:19

Edição 55 - SQL Magazine 29

DeSenvoLviMenTo

Vejamos agora alguns exemplos bas-tante comuns de regras de negócios:

• O produto X só pode ser produzido em lotes de 10 peças;

• Um novo cliente não pode incluir um pedido com valor superior a R$ 1.000,00;

• O saldo em estoque não pode ser negativo;

• Nenhuma nota fiscal pode ter seu ven-cimento em um domingo ou feriado;

• O produto Y só pode ser vendido em lotes de 1.000 peças;

• Novos pedidos devem ser automatica-mente emitidos caso o estoque dos produ-tos cheguem a uma quantidade mínima.

Recursos para manter as regras de negócios no banco de dados

Antes de apresentarmos algumas das vantagens e desvantagens de manter as re-gras de negócios no banco de dados vamos apresentar os recursos disponíveis para controle das regras de negócios no SGBD.

Os bancos de dados modernos dis-ponibilizam recursos extremamente poderosos para controle das regras de negócios, esses recursos são: integri-dade referencial, stored procedures, contraints, triggers e views. Uma das grandes vantagens de manter as regras de negócios no banco de dados é que existe a garantia da consistência das in-formações, não importando de onde veio o comando de atualização (por exemplo: se o usuário incluir um registro pela apli-cação ou por qualquer outra ferramenta existe a garantia de que as informações inseridas serão validades pelo BD).

Para entender melhor, vamos mostrar um pequeno exemplo onde as regras de negócios são mantidas pela aplicação, e veremos o que acontece quando um usuário inclui um registro utilizando

alguma outra ferramenta sem passar pela aplicação (por exemplo, utilizando uma ferramenta de administração do BD). Supondo um caso onde o código de um produto não possa ser menor que “1000” vejamos como esta regra seria implementada na aplicação. Ob-serve na Figura 1 a estrutura da tabela de produtos a qual utilizaremos como exemplo, e na Figura 2 a aplicação exemplo em execução.

Até aqui você pode perceber que as regras de negócios jamais serão viola-das, pois a aplicação não permite que isto seja feito. Porém, vamos incluir agora um registro pelo SQL Server Management Studio. Dessa forma, as regras de negócios serão violadas, como pode ser observado na Figura 3. Manter as regras de negócios no banco de dados evitaria este problema.

A situação mostrada acima é apenas um exemplo de como as regras de

Figura 1. Tabela de produtos onde o código de produto não pode ser menor que “1000”

Figura 2. Aplicação exemplo contendo a regra de negócios

Figura 3. Violando as regras de negócios

negócios poderiam ser violadas. É claro que esta não é uma boa pratica. As informações no SGBD só devem ser manipuladas pela aplicação, nunca di-retamente na base de dados, justamente porque as regras de negócios podem não estar no SGBD. Da mesma maneira que as regras de negócios foram vio-ladas no exemplo dado, poderiam ser violadas por uma falha na aplicação.

Controlando as regras de negócios com triggers

Um dos recursos mais poderosos ofe-recidos pelos bancos de dados são os triggers, que são procedures executadas sempre que um evento ocorre na tabela, seja ele inclusão, exclusão ou alteração de algum registro (você pode criar um trigger para cada evento). Vejamos agora como resolvemos o problema descrito anteriormente usando trigger. Na Lis�tagem 1 temos uma trigger criada para

SQL55.indb 29 04.07.08 11:29:21

30 SQL Magazine - Mantendo as regras de negócios no banco de dados: os prós e os contras

Figura 4. Tentativa de incluir dados incorretos na tabela tblProduto

Figura 5. Executando a stored procedure com informações incorretas

Figura 6. Tentativa de inserir informações inválidas na view

Figura 7. Inserindo dados através da view

Figura 8. Erro ao instanciar a classe Produto com informações incorretas

evitar que sejam incluídos na tabela tbl-Produto registros com código de produto menor que 1.000.

Na Figura 4 você pode perceber que agora as informações incorretas não são mais aceitas, pois sempre que forem incluídas serão antes validadas pela trigger. Com isto, eliminamos o risco de alteração inadequada da base de dados, não importando a ferramenta utilizada para incluir as informações no banco de dados.

Controlando as regras de negócios com stored procedures

Outra maneira de manter as regras de negócios no banco de dados é o uso de stored procedures. A idéia aqui é que o usuário não tenha acesso direto às tabelas do banco de dados. As inclusões, exclusões e ou alterações de registros serão feitas por stored procedures. Neste caso, a aplicação apenas executa a stored procedure enviando os parâmetros ne-cessários, em seguida a stored procedure verifica se as informações não violam as regras de negócios e, somente depois, as informações são manipuladas no banco de dados. Veremos agora como imple-mentar a regra de exemplo do artigo, ou seja “o código do produto deve ser maior ou igual a 1000”. Na Listagem 2 você pode ver o código da stored proce-dure que faz a inclusão de produtos e na Figura 5 temos um script Transact-SQL que faz uso da stored procedure.

Controlando as regras de negócios com views

Outro recurso extremamente útil para

SQL55.indb 30 04.07.08 11:29:24

Edição 55 - SQL Magazine 31

DeSenvoLviMenTo

Listagem 1. Trigger para controlar as regras de negócios

SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOCREATE TRIGGER TR_INCLUSAO_PRODUTO ON tblPRODUTO AFTER INSERT,UPDATEAS BEGIN SET NOCOUNT ON; IF ((SELECT CodigoProduto FROM INSERTED) < 1000) BEGIN RAISERROR(‘Codigo de produto invalido’,11,1) ROLLBACK TRANSACTION END ENDGO

Listagem 2. Stored procedure para controlar as regras de negócios

CREATE PROCEDURE SP_INCLUSAOPRODUTO (@CodigoP INT, @Descricao VARCHAR(50),@LoteMinF INT,@LoteMinV INT,@PObsoleto BIT)ASBEGIN IF @CodigoP < 1000 BEGIN RAISERROR(‘Codigo de produto incorreto’,11,1) RETURN END INSERT INTO tblProduto(CodigoProduto, Descricao, LoteMinFabricacao, LoteMinVenda,ProdutoObsoleto) VALUES(@CodigoP, @Descricao, @LoteMinF, @LoteMinV,@PObsoleto)END

Listagem 3. View com a clausula “WITH CHECK OPTION” para controle das regras de negócios

CREATE VIEW VWPRODUTOASSELECT CodigoProduto,Descricao,LoteMinFabricacao,LoteMinVenda, ProdutoObsoleto FROM tblProduto WHERE CodigoProduto >= 1000WITH CHECK OPTION

manter as regras de negócios no banco de dados são as views. Da mesma manei-ra que nas stored procedures você pode bloquear o acesso direto às tabelas e libe-rar o acesso apenas às views. Você pode colocar nas views apenas as colunas as quais os usuários podem ter acesso. Usando a cláusula “WITH CHECK OP-TION” você pode evitar que o usuário viole as regras de negócios. A cláusula “WITH CHECK OPTION” funciona da seguinte maneira: ao incluir os dados através da view, o SGBD checa se a in-formação está de acordo com a condição WHERE da view e, somente se estiver de acordo, o banco de dados permite que a informação seja gravada fisicamente na tabela. Na Listagem 3 temos um exemplo de uma view utilizada para controlar as regras de negócios. Como exemplo utilizamos a mesma regra do exemplo anterior. Na Figura 6 temos o uso da view com informações incorretas e na Figura 7 temos a utilização da view com informações corretas.

A orientação a objetos e as regras de negócios

Com o estabelecimento da orienta-ção a objetos como padrão para de-senvolvimento de sistemas, tivemos um cenário um pouco diferente das antigas aplicações Cliente/Servidor. Na orientação a objetos a maioria das regras de negócios é controlada pelas próprias classes, o que diminui signi-ficativamente a necessidade de regras de negócios no banco de dados. Porém, mesmo neste caso, é interessante um estudo aprofundado do projeto que poderá levar a decisão de quais regras deverão ser mantidas nas classes e quais regras de negócios deverão ser mantidas pelo banco de dados. Veja na Listagem 4 o exemplo de regra que utilizamos até agora sendo mantido por uma classe Java.

Vejamos agora o que acontece se ten-tarmos instanciar a classe “ Produto” com informações que violam as regras de negócios. Na Listagem 5 você pode verificar o código necessário para instanciar a classe com informações incorretas e na Figura 8 você pode ver o resultado.

Manter as regras de negócios no banco dados: vantagens

Este assunto é um tanto quanto po-lêmico, alguns defendem fortemente que as regras de negócios devem ser mantidas 100% no banco de dados, afinal a maioria dos bancos modernos oferecem poderosos recursos para que as regras sejam mantidas pelo próprio banco de dados e estes recursos devem ser utilizados. Claro, os recursos podem e devem ser utilizados, porém, a utili-zação desordenada pode prejudicar e muito a performance do SGBD. Abaixo temos algumas das principais vanta-gens de manter as regras de negócios no banco de dados:

• Simplificação no código da aplicação, pois os dados no final serão validados pelas rotinas no banco de dados antes de serem aceitas pelo SGBD;

• Simplificação na manutenção das regras quando necessário, pois as re-gras estão em único lugar e não existe a necessidade de ficar redistribuindo a aplicação a cada nova alteração;

• Maior garantia na integridade das informações, pois todas as regras serão

tratadas pelo banco e estarão livres de possíveis falhas na aplicação.

Em aplicações pequenas, com poucas regras de negócios e volume baixo de transações, manter 100% das regras de negócios no banco de dados é aceitável, porém, caso a aplicação venha a crescer, esta situação poderá ficar complicada. Por isso, é importante um estudo apro-fundado antes do início do projeto para que a escolha das regras a serem manti-das no banco de dados seja correta.

Manter as regras de negócios no banco dados: desvantagens

Apesar dos bancos de dados oferecerem recursos extremamente poderosos para controlar as regras de negócios, é interes-sante tomar cuidado com isso. O excesso do uso de triggers e stored procedures pode comprometer a portabilidade da aplicação. Imagine que uma aplicação foi desenvolvida para o MySQL e agora precisa ser portada para um banco de dados com maior poder como o SQL Server, todas as regras de negócios es-critas no MySQL terão que ser reescritas

SQL55.indb 31 04.07.08 11:29:25

32 SQL Magazine - Mantendo as regras de negócios no banco de dados: os prós e os contras

para o SQL Server. Isso acontece porque apesar de a linguagem SQL ser padro-nizada, cada banco de dados apresenta sua própria extensão da linguagem. Por exemplo: o SQL Server implementa a Transact-SQL, o Oracle implementa a PL/SQL e o DB2 implementa a SQL PL. Todas as implementações citadas apre-sentam diferenças entre si, o que dificulta bastante a portabilidade. Outro detalhe importante é que mantendo as regras de negócios 100% no banco de dados você estaria sobrecarregando seu SGBD, tornando-o lento e comprometendo as suas principais funções que é manter as informações e disponibiliza-las sempre que forem solicitadas.

Os sistemas ERP e as regras de negócios

Os sistemas ERP (Enterprise Resource Planning) normalmente são construídos para funcionar em qualquer banco de dados, o que torna complicado e até inviável manter as regras de negócios no banco de dados, pois depende do cliente a opção de banco de dados a ser usado. Imagine a complexidade deste processo: todas as stored procedures, triggers, etc precisariam ser reescritas para cada banco de dados, o que tornaria a aplicação extremamente complexa e de difícil manutenção. É muito comum encontrarmos sistemas ERP com nenhu-ma regra de negócio mantida no banco de dados. Isso é vantajoso, pois facilita a portabilidade da aplicação entre banco de dados diferentes. Este é um exemplo de situação onde não é recomendável manter as regras no banco de dados.

Aplicações em n camadasUma das maneiras mais inteligentes

de controlar as regras de negócios sem sobrecarregar a aplicação ou o banco de dados é utilizar aplicações n camadas. No modelo de n camadas temos em cada camada um recurso responsável por determinada operação. Veja abaixo como seria uma aplicação de três ca-madas, cada uma com uma atribuição específica:

• Camada de apresentação: esta ca-mada é responsável pela interface do usuário. É através dela que o usuário

Figura 9. Esquema de uma aplicação em três camadas, onde as regras de negócios são controladas pelo servidor de aplicações

Listagem 4. Mantendo as regras de negócios nos objetos

public class Produto { private int Codigo; private String Descricao; private int LoteMinF; private int LoteMinV; private byte ProdutoO; Produto(int CodigoP, String Desc, int LMF, int LMV, byte PO) throws CodigoInvalidoException { if(CodigoP < 1000) { throw new CodigoInvalidoException(); } Codigo = CodigoP; Descricao = Desc; LoteMinF = LMF; LoteMinV = LMV; ProdutoO = PO; } void setCodigo(int CodigoP) throws CodigoInvalidoException { if(CodigoP < 1000) { throw new CodigoInvalidoException(); } this.Codigo = CodigoP; }}class CodigoInvalidoException extends Exception { CodigoInvalidoException() { super(“Codigo invalido”); } }

Listagem 5. Tentativa de instanciar a classe produto com informações incorretas

package regras;import javax.swing.*;public class Main { public static void main(String[] args) { Produto P; try { P = new Produto(1,”iPod nano”,500,250,(byte)0); } catch(Exception e) { JOptionPane.showMessageDialog(null,e.getMessage(),“Erro ao instanciar o objeto”,2); } }}

SQL55.indb 32 04.07.08 11:29:27

Edição 55 - SQL Magazine 33

DeSenvoLviMenTo

Dê seu feedback sobre esta edição!

A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

Dê seu voto sobre este artigo, através do link:

www.devmedia.com.br/sqlmagazine/feedback

Dê

seu Feedback

sob

re esta edição

pode ter acesso aos dados armazenados em bancos de dados;

• Camada de controle: aqui são manti-das as regras de negócios, as operações solicitadas pelos clientes serão validadas na camada de controle antes de serem enviadas ao banco de dados;

• Camada de dados: esta camada é representada pelo banco de dados, neste modelo o banco é responsável apenas por manter as informações. As regras de negócios seriam controladas pela camada de controle.

Na Figura 9 temos um esquema de uma aplicação em três camadas. Neste esque-ma você pode verificar que: o acesso ao SGBD é feito pelo servidor de aplicações, o cliente não tem acesso direto ao SGBD, todos os seus pedidos são enviados ao servidor de aplicações o qual verifica se o pedido do cliente não viola as regras de negócios da empresa e só depois envia as informações ao SGBD.

Este é um exemplo de aplicação onde normalmente mantemos parte das re-gras de negócio na própria aplicação.

Afinal, manter ou não as regras de negócios no bancos de dados?

Não é simples decidir entre manter ou não as regras de negócios no banco de dados. O fato de existir a possibilidade de troca de banco de dados é um motivo para se decidir não manter as regras no banco de dados ou manter o mínimo possível.

Nos casos onde não existe a possibi-lidade de troca de banco, o melhor a se fazer é balancear a carga entre a aplica-ção e o banco de dados. Desta maneira, você não vai sobrecarregar o seu SGBD e nem a sua aplicação.

É claro que manter uma aplicação N camadas onde existe um servidor responsável por controlar as regras de negócios é a melhor solução. Porém, não é possível utilizar esta abordagem em

todos os projetos devido a vários fatores, por exemplo, o custo.

ConclusãoO assunto que tratamos neste artigo é um

tanto quanto polêmico, procuramos mos-trar as vantagens e desvantagens de cada escolha. As opiniões quanto a este assunto variam muito de um profissional para outro, porém, os fatos que apresentamos aqui devem ser levados em consideração na hora de decidir entre manter ou não as regras de negócios no banco de dados. Esperamos que as idéias apresentadas sejam úteis no desenvolvimento de seus próximos projetos.

Faça um up grade em sua carreira.

Em um mercado cada vez mais focado em qualidade ter conhecimentos apro-fundados sobre requisitos, metodologia, análises, testes, entre outros, pode ser a diferença entre conquistar ou não uma boa posição profissional. Sabendo disso a DevMedia lança para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software. Todos os meses você irá encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven) ; ALM (appl ica t ion lifecycle management); SOA (aplicações orientadas a servicos); Analise de sistemas; modelagem; Métricas; orientação à objetos; UML; testes e muito mais. Assine já!

Conhecimento faz diferença!

Faça já sua assinatura digital! | www.devmedia.com.br/es

Edição Especial

ProjetoEntenda o conceito de Arquitetura de Software e

como trabalhar com os Estilos Arquiteturais

RequisitosConheça os principais conceitos envolvidos

na Engenharia de Requisitos

Verificação, Validação & TesteFerramentas Open Source e melhores

práticas na gestão de defeitos

Especial Processos

Melhore seus processos através da análise de risco e conformidade

Veja como integrar conceitos de Modelos Tradicionais e Ágeis

Veja como integrar o Processo Unificado ao desenvolvimento Web

mag

azin

e

Entenda os principais conceitos sobreTestes e Inspeção de Software

Engenharia de SoftwareSaiba seu significado e para que serve

Capa ESM - Final .pdf 19.02.08 18:15:13

Mais de 60 mil downloadsna primeira edição!

SQL55.indb 33 04.07.08 11:29:32