Mantendo as regras de negcios no banco

de dados: os prs e os contras

[ Banco de Dados ]

odo sistema empresarial tem

como principal funo assegurar que as regras de negcios da
empresa sejam obedecidas, garantindo
a consistncia das informaes e fornecendo dados importantes aos gestores
que podem ser usados em tomadas
de decises. Portanto, a qualidade e
confiabilidade das informaes manipuladas devem ser fator primordial nos
sistemas empresariais. Neste artigo
veremos os casos em que interessante manter estas regras de negcios no
banco de dados e os casos em que essa
prtica se torna invivel.

O que so regras de negcios

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 Cincia da Computao pela Univap - Universidade do Vale do Paraba. Atua como
consultor pela empresa Compasso em projetos
Visual Basic e Java com banco de dados Oracle.

28
SQL55.indb 28

As regras de negcios determinam

como uma empresa funciona, o que
dever ser feito e como deve ser feito. As
regras de negcios variam de empresa
para empresa, porm, empresas do
mesmo ramo de atividade normalmente
tm regras de negcios semelhantes.
A definio para regras de negcios

a seguinte: So declaraes que apresentam a maneira como o negcio est

sendo feito, alm das diretrizes e restries com respeito a estados e processos
em uma determinada organizao. As
regras de negcios normalmente podem
ser classificadas em dois tipos:
Regras de integridade: representam
a semntica das restries de integridade. Neste caso, uma regra foi violada
e uma condio de erro deve obrigatoriamente ser disparada. Um exemplo
seria uma regra onde o estoque de um
produto no poderia ficar negativo. Se
alguma operao levar a esta condio
um erro deve ser lanado e a operao
deve ser cancelada;
Regras de automatizao: neste caso
no existe violao de regra, apenas uma
situao onde uma tarefa deve ser disparada automaticamente, ou seja, sem interveno do usurio. Um exemplo seria uma
condio onde novos pedidos devem ser
includos para um produto caso seu estoque chegue a uma quantidade mnima.

SQL Magazine - Mantendo as regras de negcios no banco de dados: os prs e os contras

04.07.08 11:29:19

Desenvolvimento

Vejamos agora alguns exemplos bastante comuns de regras de negcios:

O produto X s pode ser produzido
em lotes de 10 peas;
Um novo cliente no pode incluir um
pedido com valor superior a R$ 1.000,00;
O saldo em estoque no pode ser
negativo;
Nenhuma nota fiscal pode ter seu vencimento em um domingo ou feriado;
O produto Y s pode ser vendido em
lotes de 1.000 peas;
Novos pedidos devem ser automaticamente emitidos caso o estoque dos produtos cheguem a uma quantidade mnima.

Recursos para manter as regras de

negcios no banco de dados

Antes de apresentarmos algumas das

vantagens e desvantagens de manter as regras de negcios no banco de dados vamos
apresentar os recursos disponveis para
controle das regras de negcios no SGBD.
Os bancos de dados modernos disponibilizam recursos extremamente
poderosos para controle das regras de
negcios, esses recursos so: integridade referencial, stored procedures,
contraints, triggers e views. Uma das
grandes vantagens de manter as regras
de negcios no banco de dados que
existe a garantia da consistncia das informaes, no importando de onde veio
o comando de atualizao (por exemplo:
se o usurio incluir um registro pela aplicao ou por qualquer outra ferramenta
existe a garantia de que as informaes
inseridas sero validades pelo BD).
Para entender melhor, vamos mostrar
um pequeno exemplo onde as regras de
negcios so mantidas pela aplicao,
e veremos o que acontece quando um
usurio inclui um registro utilizando

Figura 1. Tabela de produtos onde o cdigo

de produto no pode ser menor que 1000

Figura 2. Aplicao exemplo contendo a regra

de negcios

Figura 3. Violando as regras de negcios

alguma outra ferramenta sem passar

pela aplicao (por exemplo, utilizando
uma ferramenta de administrao do
BD). Supondo um caso onde o cdigo
de um produto no possa ser menor
que 1000 vejamos como esta regra
seria implementada na aplicao. Observe na Figura 1 a estrutura da tabela
de produtos a qual utilizaremos como
exemplo, e na Figura 2 a aplicao
exemplo em execuo.
At aqui voc pode perceber que as
regras de negcios jamais sero violadas, pois a aplicao no permite que
isto seja feito. Porm, vamos incluir
agora um registro pelo SQL Server
Management Studio. Dessa forma,
as regras de negcios sero violadas,
como pode ser observado na Figura 3.
Manter as regras de negcios no banco
de dados evitaria este problema.
A situao mostrada acima apenas
um exemplo de como as regras de

negcios poderiam ser violadas.

claro que esta no uma boa pratica.
As informaes no SGBD s devem ser
manipuladas pela aplicao, nunca diretamente na base de dados, justamente
porque as regras de negcios podem
no estar no SGBD. Da mesma maneira
que as regras de negcios foram violadas no exemplo dado, poderiam ser
violadas por uma falha na aplicao.

Controlando as regras de negcios

com triggers

Um dos recursos mais poderosos oferecidos pelos bancos de dados so os

triggers, que so procedures executadas
sempre que um evento ocorre na tabela,
seja ele incluso, excluso ou alterao
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

Edio 55 - SQL Magazine

SQL55.indb 29

29

04.07.08 11:29:21

Figura 4. Tentativa de incluir dados incorretos na tabela tblProduto

evitar que sejam includos na tabela tblProduto registros com cdigo de produto
menor que 1.000.
Na Figura 4 voc pode perceber que
agora as informaes incorretas no
so mais aceitas, pois sempre que
forem includas sero antes validadas
pela trigger. Com isto, eliminamos o
risco de alterao inadequada da base
de dados, no importando a ferramenta
utilizada para incluir as informaes
no banco de dados.

Controlando as regras de negcios

com stored procedures

Figura 5. Executando a stored procedure com informaes incorretas

Figura 6. Tentativa de inserir informaes invlidas na view

Outra maneira de manter as regras de

negcios no banco de dados o uso de
stored procedures. A idia aqui que
o usurio no tenha acesso direto s
tabelas do banco de dados. As incluses,
excluses e ou alteraes de registros
sero feitas por stored procedures. Neste
caso, a aplicao apenas executa a stored
procedure enviando os parmetros necessrios, em seguida a stored procedure
verifica se as informaes no violam as
regras de negcios e, somente depois, as
informaes so manipuladas no banco
de dados. Veremos agora como implementar a regra de exemplo do artigo,
ou seja o cdigo do produto deve ser
maior ou igual a 1000. Na Listagem 2
voc pode ver o cdigo da stored procedure que faz a incluso de produtos e na
Figura 5 temos um script Transact-SQL
que faz uso da stored procedure.

Controlando as regras de
negcios com views

Outro recurso extremamente til para

Figura 7. Inserindo dados atravs da view

30
SQL55.indb 30

Figura 8. Erro ao instanciar a classe Produto

com informaes incorretas

SQL Magazine - Mantendo as regras de negcios no banco de dados: os prs e os contras

04.07.08 11:29:24

Desenvolvimento

manter as regras de negcios no banco

de dados so as views. Da mesma maneira que nas stored procedures voc pode
bloquear o acesso direto s tabelas e liberar o acesso apenas s views. Voc pode
colocar nas views apenas as colunas
as quais os usurios podem ter acesso.
Usando a clusula WITH CHECK OPTION voc pode evitar que o usurio
viole as regras de negcios. A clusula
WITH CHECK OPTION funciona da
seguinte maneira: ao incluir os dados
atravs da view, o SGBD checa se a informao est de acordo com a condio
WHERE da view e, somente se estiver de
acordo, o banco de dados permite que a
informao seja gravada fisicamente na
tabela. Na Listagem 3 temos um exemplo
de uma view utilizada para controlar
as regras de negcios. Como exemplo
utilizamos a mesma regra do exemplo
anterior. Na Figura 6 temos o uso da
view com informaes incorretas e na
Figura 7 temos a utilizao da view com
informaes corretas.

A orientao a objetos e as
regras de negcios

Com o estabelecimento da orientao a objetos como padro para desenvolvimento de sistemas, tivemos
um cenrio um pouco diferente das
antigas aplicaes Cliente/Servidor.
Na orientao a objetos a maioria das
regras de negcios controlada pelas
prprias classes, o que diminui significativamente a necessidade de regras
de negcios no banco de dados. Porm,
mesmo neste caso, interessante um
estudo aprofundado do projeto que
poder levar a deciso de quais regras
devero ser mantidas nas classes e
quais regras de negcios devero 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 tentarmos instanciar a classe Produto
com informaes que violam as regras
de negcios. Na Listagem 5 voc pode
verificar o cdigo necessrio para
instanciar a classe com informaes
incorretas e na Figura 8 voc pode
ver o resultado.

Listagem 1. Trigger para controlar as regras de negcios

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TRIGGER TR_INCLUSAO_PRODUTO
ON tblPRODUTO
AFTER INSERT,UPDATE
AS
BEGIN
SET NOCOUNT ON;

IF ((SELECT CodigoProduto FROM INSERTED) < 1000) BEGIN
RAISERROR(Codigo de produto invalido,11,1)
ROLLBACK TRANSACTION
END
END
GO

Listagem 2. Stored procedure para controlar as regras de negcios

CREATE PROCEDURE SP_INCLUSAOPRODUTO (
@CodigoP INT,
@Descricao VARCHAR(50),
@LoteMinF INT,
@LoteMinV INT,
@PObsoleto BIT)
AS
BEGIN
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 negcios
CREATE VIEW VWPRODUTO
AS
SELECT CodigoProduto,Descricao,LoteMinFabricacao,LoteMinVenda, ProdutoObsoleto FROM tblProduto
WHERE CodigoProduto >= 1000
WITH CHECK OPTION

Manter as regras de negcios no

banco dados: vantagens

Este assunto um tanto quanto polmico, alguns defendem fortemente

que as regras de negcios devem ser
mantidas 100% no banco de dados,
afinal a maioria dos bancos modernos
oferecem poderosos recursos para que
as regras sejam mantidas pelo prprio
banco de dados e estes recursos devem
ser utilizados. Claro, os recursos podem
e devem ser utilizados, porm, a utilizao desordenada pode prejudicar e
muito a performance do SGBD. Abaixo
temos algumas das principais vantagens de manter as regras de negcios
no banco de dados:
Simplificao no cdigo da aplicao,
pois os dados no final sero validados
pelas rotinas no banco de dados antes
de serem aceitas pelo SGBD;
Simplificao na manuteno das
regras quando necessrio, pois as regras esto em nico lugar e no existe
a necessidade de ficar redistribuindo a
aplicao a cada nova alterao;
Maior garantia na integridade das
informaes, pois todas as regras sero

tratadas pelo banco e estaro livres de

possveis falhas na aplicao.
Em aplicaes pequenas, com poucas
regras de negcios e volume baixo de
transaes, manter 100% das regras de
negcios no banco de dados aceitvel,
porm, caso a aplicao venha a crescer,
esta situao poder ficar complicada.
Por isso, importante um estudo aprofundado antes do incio do projeto para
que a escolha das regras a serem mantidas no banco de dados seja correta.

Manter as regras de negcios no

banco dados: desvantagens

Apesar dos bancos de dados oferecerem

recursos extremamente poderosos para
controlar as regras de negcios, interessante tomar cuidado com isso. O excesso
do uso de triggers e stored procedures
pode comprometer a portabilidade da
aplicao. Imagine que uma aplicao
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 negcios escritas no MySQL tero que ser reescritas

Edio 55 - SQL Magazine

SQL55.indb 31

31

04.07.08 11:29:25

Listagem 4. Mantendo as regras de negcios 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 informaes 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);
}
}
}

para o SQL Server. Isso acontece porque

apesar de a linguagem SQL ser padronizada, cada banco de dados apresenta
sua prpria extenso 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 implementaes citadas apresentam diferenas entre si, o que dificulta
bastante a portabilidade. Outro detalhe
importante que mantendo as regras
de negcios 100% no banco de dados
voc estaria sobrecarregando seu SGBD,
tornando-o lento e comprometendo as
suas principais funes que manter as
informaes e disponibiliza-las sempre
que forem solicitadas.

Os sistemas ERP e as regras

de negcios

Os sistemas ERP (Enterprise Resource

Planning) normalmente so construdos
para funcionar em qualquer banco de
dados, o que torna complicado e at
invivel manter as regras de negcios
no banco de dados, pois depende do
cliente a opo 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 aplicao extremamente complexa e
de difcil manuteno. muito comum
encontrarmos sistemas ERP com nenhuma regra de negcio mantida no banco
de dados. Isso vantajoso, pois facilita
a portabilidade da aplicao entre banco
de dados diferentes. Este um exemplo
de situao onde no recomendvel
manter as regras no banco de dados.

Aplicaes em n camadas

Figura 9. Esquema de uma aplicao em trs camadas, onde as regras de negcios so controladas
pelo servidor de aplicaes

32
SQL55.indb 32

Uma das maneiras mais inteligentes

de controlar as regras de negcios sem
sobrecarregar a aplicao ou o banco de
dados utilizar aplicaes n camadas.
No modelo de n camadas temos em
cada camada um recurso responsvel
por determinada operao. Veja abaixo
como seria uma aplicao de trs camadas, cada uma com uma atribuio
especfica:
Camada de apresentao: esta camada responsvel pela interface do
usurio. atravs dela que o usurio

SQL Magazine - Mantendo as regras de negcios no banco de dados: os prs e os contras

04.07.08 11:29:27

Desenvolvimento

todos os projetos devido a vrios fatores,

por exemplo, o custo.

Afinal, manter ou no as regras de

negcios no bancos de dados?

O assunto que tratamos neste artigo um

tanto quanto polmico, procuramos mostrar as vantagens e desvantagens de cada
escolha. As opinies quanto a este assunto
variam muito de um profissional para
outro, porm, os fatos que apresentamos
aqui devem ser levados em considerao
na hora de decidir entre manter ou no
as regras de negcios no banco de dados.
Esperamos que as idias apresentadas
sejam teis no desenvolvimento de seus
prximos projetos.
D seu feedback sobre esta edio! eu Feedback

No simples decidir entre manter ou

no as regras de negcios no banco de
dados. O fato de existir a possibilidade
de troca de banco de dados um motivo
para se decidir no manter as regras no
banco de dados ou manter o mnimo
possvel.
Nos casos onde no existe a possibilidade de troca de banco, o melhor a se
fazer balancear a carga entre a aplicao e o banco de dados. Desta maneira,
voc no vai sobrecarregar o seu SGBD
e nem a sua aplicao.
claro que manter uma aplicao
N camadas onde existe um servidor
responsvel por controlar as regras de
negcios a melhor soluo. Porm, no
possvel utilizar esta abordagem em

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, atravs do link:

www.devmedia.com.br/sqlmagazine/feedback

Conhecimento faz diferena!

Capa ESM - Final .pdf

19.02.08

Faa um up grade em sua carreira.

18:15:13

magazine

Engenharia de Software
Saiba seu significado e para que serve

Ferramentas Open Source e melhores

prticas na gesto de defeitos

Requisitos

Conhea os principais conceitos envolvidos

na Engenharia de Requisitos

Especial

Projeto

Entenda o conceito de Arquitetura de Software e

como trabalhar com os Estilos Arquiteturais




  

Entenda os principais conceitos sobre

Testes e Inspeo de Software



Edio Especial

Verificao, Validao & Teste

D
s

Concluso

sobre e
s

Na Figura 9 temos um esquema de uma

aplicao em trs camadas. Neste esquema voc pode verificar que: o acesso ao
SGBD feito pelo servidor de aplicaes,
o cliente no tem acesso direto ao SGBD,
todos os seus pedidos so enviados ao
servidor de aplicaes o qual verifica se
o pedido do cliente no viola as regras
de negcios da empresa e s depois envia
as informaes ao SGBD.

Este um exemplo de aplicao onde

normalmente mantemos parte das regras de negcio na prpria aplicao.

edio
ta

pode ter acesso aos dados armazenados

em bancos de dados;
Camada de controle: aqui so mantidas as regras de negcios, as operaes
solicitadas pelos clientes sero 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 responsvel apenas
por manter as informaes. As regras
de negcios seriam controladas pela
camada de controle.

Em um mercado cada vez mais focado

em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia,
anlises, testes, entre outros, pode ser a
diferena entre conquistar ou no uma
boa posio profissional. Sabendo disso a
DevMedia lana 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 (application lifecycle
management); SOA (aplicaes orientadas
a servicos); Analise de sistemas; modelagem;
Mtricas; orientao objetos; UML; testes
e muito mais. Assine j!

Mais de 60 mil downloads

na primeira edio!

Processos

Melhore seus processos atravs da

anlise de risco e conformidade

Veja como integrar conceitos de

Modelos Tradicionais e geis

Veja como integrar o Processo

Unificado ao desenvolvimento Web

Faa j sua assinatura digital! | www.devmedia.com.br/es

Edio 55 - SQL Magazine

SQL55.indb 33

33

04.07.08 11:29:32