Atila Cordeiro Biolchi

UNIVERSIDADE REGIONAL DO NOROESTE DO
ESTADO DO RIO GRANDE DO SUL

DEPARTAMENTO DE CIÊNCIAS EXATAS E
ENGENHARIAS
CIÊNCIA DA COMPUTAÇÃO
ÁTILA CORDEIRO BIOLCHI
AVALIAÇÃO DA IMPLEMENTAÇÃO DE
REGRAS DE NEGÓCIO EM POSTGRESQL
Ijuí - RS
2017
ÁTILA CORDEIRO BIOLCHI
AVALIAÇÃO DA IMPLEMENTAÇÃO DE REGRAS DE

NEGÓCIO EM POSTGRESQL
Trabalho apresentado ao curso de Ciência

da Computação da Universidade Regional
do Noroeste do Estado do Rio Grande do
Sul, como requisito para a obtenção do tí-
tulo de Bacharel em Ciência da Computa-
ção.
Orientador: Prof. Me. Leonardo Minelli
Ijuí - RS
2017
Dedico este trabalho a minha esposa Danieli Biolchi e meu
filho Luís Otávio de Oliveira Biolchi, que me forneceram
apoio em todo o período do curso,
além de me dar motivação para superar todas as
dificuldades durante a graduação.
AGRADECIMENTOS
Agradeço primeiramente ao meu filho Luís Otávio, que mesmo com pouca
idade soube compreender as minhas ausências e servir de motivação para alcançar o
objetivo final.
A minha esposa, Danieli, que sempre me deu força e coragem para superar as
dificuldades de cada etapa da graduação.
Também agradeço a minha mãe, Suzete, que me incentivou a nunca deixar

de buscar meus objetivos. Aos meus irmãos Tarcísio e Luciano que sempre serviram
como referência de ética e persistência .
Agradeço ainda ao professor Leonardo Minelli, que me orientou durante o

desenvolvimento do trabalho de conclusão de curso que proporcionou várias trocas de
informações, além de todas as sugestões de melhorias que aumentaram a credibilidade
da pesquisa.
Por fim, agradeço ao Dionei Buske, Lucas Gerhardt e Júlio Beal que apostaram
no meu trabalho quando iniciei minhas atividades na Coordenadoria de Informática,
sem os benefícios fornecidos pela UNIJUÍ minha caminhada acadêmica não seria
possível, sou muito grato por isso.
"Você nunca alcança o sucesso verdadeiro a menos
que você goste do que está fazendo."
(Dale Carnegie)
RESUMO
Com o aumento da complexidade dos sistemas de informação cresce também as
dificuldades em manter e gerenciar as regras de negócio. O gerenciamento, a im-
plementação e o reuso destas regras podem ser determinantes para o aumento da
qualidade e produtividade no desenvolvimento do software. Desta forma, a utilização
das ferramentas existentes nos Sistemas Gerenciadores de Banco de Dados(SGBD)
podem ser uma alternativa para centralização de regras de negócio complexas. Grande
parte dos SGBD’s oferecem suporte para implementação de Procedimento, Funções
e Programação Procedural SQL, um deles é o PostgreSQL Database Management
System, distribuído sob uma licença Open Source, possibilitando assim ser objeto de
estudo do presente trabalho.
Palavras-chaves: Banco de Dados, Regra de Negocio, SGBD, Multicamadas, PL/SQL.

ABSTRACT
With the increasing complexity of information systems, the difficulties in maintaining and
managing business rules also increase. The management, implementation, and reuse of
these rules can be instrumental in increasing quality and productivity in software devel-
opment. In this way, the use of existing tools in Database Management Systems (DBMS)
can be an alternative for centralizing complex business rules. Most DBMSs support the
implementation of Procedural Procedures, Functions and Procedural SQL Programming,
one of them is the PostgreSQL Database Management System, distributed under an
Open Source license, thus making it possible to study this work.
Keywords: Database, Business Rules, DBMS, Multi-layer, PL/SQL.

LISTA DE ILUSTRAÇÕES
Figura 1 – Modelo de três camadas . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figura 2 – Modelo n camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figura 3 – Modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 4 – Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 5 – Estrutura de uma View . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 6 – Exemplo de uma View composta . . . . . . . . . . . . . . . . . . . . 29
Figura 7 – Estrutura de uma Função Armazenada . . . . . . . . . . . . . . . . 30
Figura 8 – Função Armazenada do tipo tabela . . . . . . . . . . . . . . . . . . . 31
Figura 9 – Execução da função . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 10 – Execução da função . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 11 – Criação da função . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 12 – Criação da função . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 13 – Criação do Gatilho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 14 – Recorte da figura 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 15 – Diagrama do processo utilizando ferramenta do site (BPMN.IO, 2016) 36
Figura 16 – Tela de Ordens de Serviço . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 17 – Insert Em ALTERACOES_OS . . . . . . . . . . . . . . . . . . . . . . 38
Figura 18 – Início da implementação da regra . . . . . . . . . . . . . . . . . . . . 38
Figura 19 – Implementação da regra de negócio . . . . . . . . . . . . . . . . . . 39
Figura 20 – Consulta adicional para a regra de negócio . . . . . . . . . . . . . . 40
Figura 21 – Implementação da completa da regra de negócio . . . . . . . . . . . 41
Figura 22 – Estrutura do Catalogo . . . . . . . . . . . . . . . . . . . . . . . . . . 42
LISTA DE TABELAS
Tabela 1 – Resultado da Execução . . . . . . . . . . . . . . . . . . . . . . . . . 30

LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
DB Database
IDE Integrated Development Environment
PG PostgreSQL
PL/SQL Procedural Language
PL/pgSQL Procedural Language PostgreSQL
RAD Rapid Application Development
SGBD Sistema de Gerenciamento de Banco de dados
SQL Structured Query Language

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Arquitetura multicamadas . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Camada de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Camada de Regras de Negócio . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Camada de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Implementação de regras na Camada de Negócio . . . . . . . . . 20
2.3 Implementação de regras na Camada de Dados . . . . . . . . . . 21
2.3.1 PostgreSQL e as Regras de Negócio . . . . . . . . . . . . . . . . . . 22
2.3.2 Funções definidas pelo usuário . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Linguagem procedural para SQL . . . . . . . . . . . . . . . . . . . . 25
3 MODELAGEM E ESTUDO DE CASO . . . . . . . . . . . . . . . . . . 26

3.1 A Linguagem de Programação . . . . . . . . . . . . . . . . . . . . . 26
3.2 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 A linguagem SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Visões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Funções Armazenadas SQL . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Procedimentos Armazenados . . . . . . . . . . . . . . . . . . . . . 33
3.7 Gatilhos de Procedimentos . . . . . . . . . . . . . . . . . . . . . . 34
4 IMPLEMENTAÇÃO DO ESTUDO DE CASO . . . . . . . . . . . . . . 35

4.1 Delimitação da Implementação . . . . . . . . . . . . . . . . . . . . 35
4.2 A implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Tipo de Implementação escolhida . . . . . . . . . . . . . . . . . . . . 38
4.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ANEXOS 47
ANEXO A – SCRIPT DE CRIAÇÃO DO BANCO DE DADOS . . . . 48

ANEXO B – SCRIPT PARA POPULAR O BANCO DE DADOS . . . 51
1 INTRODUÇÃO
As regras de negócio podem ser definidas como um conjunto de práticas de

negócios que tem por o objetivo descrever como uma determinada tarefa é executada.
Na literatura pode ser encontrada como lógica de negócio. Em softwares, esta lógica é
definida no momento da análise das funcionalidades do sistema.
De acordo com (HAY; HEALY, 1997) regras de negócio podem aparecer de

muitas formas, podendo ser descritas de muitas formas diferentes como por exemplo,
formal e informal. As regras de negócio proporcionam às organizações uma forma
eficaz para a definição de padrões.
A criação das regras de negócio são muito complexa, pois necessita-se ter uma
ampla visão da funcionalidade que se quer implementar. Por vezes o desenvolvimento
se dá com o auxílio da utilização de tabelas de decisão ou árvores de decisão. Também
é possível determinar graficamente a sequência de execução da regra de negócios
usando um fluxo de regra ou casos de uso.
No modelo de sistema de três ou mais camadas, conhecido por n-camada, a

segunda camada é destinada para a implementação das regras de negócio. Em siste-
mas complexos um nível mais elevado de abstração tende aumentar a produtividade
de desenvolvimento, neste sentido o modelo multicamadas é muito eficaz.
Há também uma camada destinada ao banco de dados, nesta camada por de-
finição, estão todas as bases de dados que o sistema acessa.Sistemas Gerenciadores
de Banco de Dados (SGBD), tem a incumbência de organizar os dados.
Estes sistemas em suas versões mais recentes, permitem a implementação

de regra de negócio visando encapsular lógica complicada, promovendo abstração
maior no desenvolvimento da aplicação de interface com o usuário. Nestes SGBDs
também podem ser utilizados os procedimentos e funções armazenados, todas estas
funcionalidades promovem um aumento na segurança do banco de dados e podem
reduzir o trafego na rede.
De acordo (POSTGRESQL, 2015), um banco de dados de classe corporativa

como o PostgreSQL, possui recursos sofisticados, como o Controle de Concorrência,
controle recuperação de pontos, gestão de espaços de tabela, replicação assíncrona,
transações aninhadas, um planejador ou otimizador de consultas, tolerância a falhas.
Ainda segundo (POSTGRESQL, 2015), o PostgreSQL suporta conjuntos de

caracteres internacionais, codificações de caracteres multibyte, Unicode. Além destes
13
pontos é altamente escalável para grande quantidade. Existem sistemas ativos do

PostgreSQL em ambientes de produção que gerenciam mais de 4 terabytes de dados.
Neste sentido o presente trabalho abordará técnicas de implementação de

regras de negócio em PostgreSQL, que é definido como um sistema de gerenciamento
da banco de dados relacional open source, segundo o (ENGINES, 2013) o PostgreSQL
figura entre os quatro sistemas de gerenciamento de banco de dados mais utilizados
no mundo. Além disso, fará uso destas técnica para implementar uma regra de negócio
de complexidade alta utilizando as ferramentas disponíveis no PostgreSQL.
2 REFERENCIAL TEÓRICO
Dada a complexidade citada na introdução do presente trabalho, faz se neces-

sário efetuar um estudo sobre os temas que abordam esse cenário de desenvolvimento
de sistema, tais como, arquiteturas multicamadas e regras de negócio, itens abordados
no neste capítulo.
2.1 Arquitetura multicamadas
Sabendo da complexidade dos sistemas, o desenvolvimento e a manutenção

são facilitados a partir da aplicação da técnica de desenvolvimento sistemas sob a
arquitetura multicamada, sendo esta uma evolução da arquitetura cliente/servidor, que
segundo (BATTISTI, 2003), há um servidor de aplicações cliente. Entretanto todas as
regras de negócio do sistema estão implementadas dentro da aplicação, caso seja
necessária alguma alteração, toda a aplicação cliente deve ser compilada e atualizada,
também impossibilita o reuso de regras de negocio em aplicações distintas.
A arquitetura multicamadas estabelece que, para que um projeto seja efi-

ciente e possua um baixo custo de manutenção e alta manutenibilidade,
suas regras de negócio devem sempre ficar isoladas da interface com o
usuário, de modo a não interferir em sua usabilidade e garantir a unifi-
cação do processamento dos dados relativos à aplicação. Estas regras
deveriam estar igualmente isoladas dos dados a serem obtidos, manipu-
lados ou persistidos, acoplando-se a eles o mínimo possível.(SANTOS,
2014)
A multicamada implementa uma lógica de objetos distribuídos vinculados

ao interfaceamento e assim executa procedimentos, isso permite que as aplicações
clientes não implementem mais a regra de negócio, e também, não precise fazer
comunicação direta com o banco de dados, possibilitando assim o reuso de métodos, e
a agilidade no desenvolvimento de sistemas.
A ideia básica do modelo de 3 camadas, é "retirar"as Regras do Negócio

do cliente e centralizá-las em um determinado ponto, o qual é chamado
de Servidor de Aplicações. O acesso ao Banco de dados é feito através
das regras contidas no Servidor de Aplicações. Ao centralizar as Regras
do Negócio em um único ponto, fica muito mais fácil a atualização
destas regras(BATTISTI, 2003).
15
Na arquitetura de sistemas a abstração é muito importante, pois permite que o

desenvolvimento e a manutenção das aplicações tenham sua eficiência melhorada, o
empilhamento de abstrações em camadas é uma técnica muito eficaz.
Esta abstração entre as camadas permite a melhor organização das regras de

negócio facilitando a organização, criação e manutenção. Oportuniza também o reuso
e o aumento da segurança uma vez que a camada de apresentação não tem acesso
direto a camada de dados conforme ilustração abaixo.
Figura 1 – Modelo de três camadas
Fonte: Battisti (2003)
Embora a implementação do modelo de 3 camadas seja a mais utilizada, este

modelo esta contido na técnica conhecida por multicamadas, tendo como uma de suas
principais característica o baixo custo na mudança da logica de negócio.
Algumas literaturas tratam o assunto multicamadas como sendo uma

aplicação em n camadas aquela desenvolvida de forma a ter várias
camadas lógicas e cada uma é auto-contida o suficiente, de forma que
a aplicação pode ser dividida em vários computadores em uma rede
distribuída(SANTOS, 2014).
Nestes modelos, uma camada acessa apenas os componentes públicos da

camada inferior, conforme o exemplo de (BATTISTI, 2003), a camada de apresentação
só pode acessar os componentes público do nível de regra de negócio, e nunca terá
interação com a camada de dados, já a camada de regras de negócio só pode acessar
os componentes público em camada de dados, entretanto não deve acessar a camada
de apresentação. Estas premissas fazem com que a segurança seja aumentada devido
ao fato de que a camada de dados só receberá requisições da camada de negócio.
De acordo com (SANTOS, 2014), o modelo de desenvolvimento multicama-

das se mostra infinitamente superior ao modelo Cliente/Servidor, pelo motivo de que
possibilita alta escalabilidade.
16
Figura 2 – Modelo n camadas
Fonte: Soares (2007)
2.1.1 Camada de Apresentação
A camada de apresentação é a interface do software, é através desta camada

que o usuário interage com o sistema. Também é chamada de Graphial User Inter-
face, pode possuir um grau elevado de abstração utilizando a capacidade gráfica dos
computadores. Interfaces gráficas bem concebidas facilitam o aprendizado do usuário.
Alterações na Interface do programa, geram a necessidade de atua-

lizar a aplicação em todos os computadores, onde esta está sendo
utilizada. Porém cabe ressaltar, que alterações na interface, são menos
frequentes do que alterações nas regras do negócio(BATTISTI, 2003).
No caso de aplicações web:
A interface pode ser composta de páginas HTML, ASP, ou qualquer

outra tecnologia capaz de gerar conteúdo para o Navegador. Com
isso alterações na interface da aplicação, são feitas diretamente no
servidor Web, sendo que estas alterações estarão, automaticamente,
disponíveis para todos os Clientes. Com isso não existe a necessidade
de reinstalar a aplicação em todos os computadores da rede cada vez
que uma alteração for feita na camada de apresentação. Fica muito
mais fácil garantir que todos estão acessando a versão mais atualizada
da aplicação. A única coisa que o cliente precisa ter instalado na sua
máquina, é o Navegador. O acesso ao Banco de dados, é feito através
do Servidor de aplicações(BATTISTI, 2003).
17
Ao contrário de um aplicação de linha de comando, como o terminal do Linux ou

o prompt de comando do Windows, sistemas com interface gráfica são muito mais fáceis
de aprender e usar, pois os comandos não precisam ser memorizados. Além disso, os
usuários não precisam saber qualquer linguagem de programação ou codificação para
utilizar estes sistemas.
Em seu estudos, (SANTOS, 2014), constatou que a camada de apresentação

fica fisicamente localizada na estação cliente, sendo assim é a responsável por fazer a
interação do usuário com o sistema. Este motivo permite entender que nesta camada,
apenas serão executados os tratamentos de telas e campos, e que geralmente acessa
somente a camada de regras de negócio, e esta por sua vez que faz as requisições ao
banco de dados.
2.1.2 Camada de Regras de Negócio
As regras de negócio são geralmente um conjunto de declarações ou condições

que ajudam a orientar ações e atividades de uma empresa e, potencialmente, de suas
partes interessadas, como funcionários, gerentes, fornecedores, clientes e outros.
Estas regras fornecem orientações relacionadas com as ações ou atividades

específicas que podem ser realizadas. Ainda ajudam a informar o desenvolvimento de
políticas e processos, incluindo a definição de requisitos para serviços, projetos e outras
iniciativas. Como eles são tipicamente fundamentais, de acordo com (BATTISTI, 2003)
as regras de negócios são geralmente de longo prazo e bastante estáticas. Quaisquer
alterações a uma regra resultará em requisitos de negócios novos ou alterados.
Qualquer empresa, independente de porte, ramo de atividade, número

de pessoas em atividade, ou volume de recursos movimentados precisa
estabelecer regras para manter suas operações sob controle,. Entende-
mos por controle o domínio das transações em curso e a existência de
mecanismos que permitam disponibilizar informações para finalidade
de acompanhamento da atividades, verificação de desempenho, identi-
ficação de desvios e prevenção de problemas. Documentos, normas,
rotinas de trabalho e, principalmente, pessoas são elementos consti-
tuintes de um Sistema de Controles Internos. Esses sistemas precisam
ser estabelecidos em sintonia com o porte da operação, sistemas infor-
matizados disponíveis e número e qualificação das pessoas envolvidas
(GUARINO, 2015).
Uma regra de negócios se refere à forma como uma organização ou empresa

opera. Além de se aplicar a indivíduos, as regras de negócio podem ser aplicadas ao
comportamento corporativo geral ou aos processos de negócios. Também podendo
aplicar-se a elementos específicos de uma organização, como o gerenciamento de
18
dados. O sentido é garantir que uma organização esteja cumprindo seus objetivos. As
melhores regras de negócios são claramente definidas, anotadas e implementadas.
A camada de regras de negócio de um sistema tem por objetivo implementar

as regras que o sistema deve seguir para efetuar as tarefas, conforme (SOARES, 2007)
são as regras que definem a maneira como os dados serão acessados e processados.
Fazem parte das Regras do Negócio, desde funções simples de va-

lidação da entrada de dados, como o cálculo do digito verificador de
um CPF, até funções mais complexas, como descontos escalonados
para os maiores clientes, de acordo com o volume da compra,legislação
fiscal, escrita contábil, etc(SOARES, 2007).
Nesta camada devem ficar as funções e regras de todo o negócio. Ainda

segundo (SOARES, 2007) inexiste uma interface para o usuário e seus dados são
voláteis.Uma regra de negócio bem definida deve ser suficientemente detalhada e
aplicada de forma eficaz.
De acordo com (MICROSOFT, 2004), as regras de negócios tem por objetivo

definir e controlar a estrutura, operação e estratégia de uma organização. As regras de
negócios podem ser formalmente definidas em manuais de procedimentos, contratos
ou acordos, ou podem existir como conhecimento incorporados em funcionários. As
regras de negócios são dinâmicas e estão sujeitas a alterações ao longo do tempo.
O mesmo autor cita ainda que podem ser encontradas em todos os tipos de
aplicativos. Finanças e seguros, e-business, transporte, telecomunicações, serviços ba-
seados na Web e personalização, e que estes são apenas alguns dos muitos domínios
empresariais regidos pelas regras de negócios. Cada um domínios de negócio com-
partilha a necessidade de transmitir estratégias, políticas e regulamentos de negócios
para o pessoal de tecnologia da informação para inclusão em aplicativos de software.
A camada de regra de negócio possibilita ao sistema agilidade e flexibilidade,

tendo em vista que possibilita o reuso, no entanto sua implementação pode se tornar
difícil devido à sua complexidade. Regras de negócios oferecem outros benefícios,
desenvolvimento mais rápido, melhor qualidade no código, facilidade de mudança,
controle centralizado.
2.1.3 Camada de Dados
A camada de dados é formada basicamente por um ou mais Sistemas Gerenci-

adores de Banco de Dados que, de acordo com (REZENDE, 2007), é um software que
possui recursos capazes de manipular as informações do banco de dados e interagir
com o usuário.
19
Um sistema gerenciador de dados(SGBD - Database Management Sys-

tem) é uma coleção de programas que permite ao usurários criar e
manter um banco de dados. O SGBD é um sistema de software de
uso geral que facilita o processo de construção, manipulação e com-
partilhamento de bancos de dados entre diversos usuários e aplicação
(ELMASRI et al., 2005, p.3).
Os bancos de dados relacionais são compostos por tabelas que se relacionam

entre si através de atributos, que são chamados de chaves físicas, onde cada chave é
única em uma tabela e corresponde a um conjunto de atributos, que podem ser vistos
como colunas de uma tabela.
Figura 3 – Modelo de dados
Fonte: próprio autor
Segundo, (DATE, 2011), os bancos de dados relacionais são constituídos por

um conjunto de tabelas com dados que se enquadram em uma categoria predefinida.
Cada tabela possui pelo menos uma categoria de dados em uma coluna e cada linha
possui uma determinada instância de dados para as categorias que estão definidas
nas colunas.
O mesmo autor ainda explica que a linguagem Structured Query Language

(SQL) é o padrão para os SGBD’s de bancos de dados relacionais. Segundo ele, os
bancos de dados relacionais são fáceis de expandir, e uma nova categoria de dados
pode ser adicionada após a criação original do banco de dados sem exigir que você
modifique todas as aplicações existentes.
É possível complementar ainda com a linguagem SQL, é possível fazer a mani-

pulação dos dados armazenados no banco, utilizando a SQL os dados são buscados
por uma solicitação que, para respeitar o modelo multicamadas, é aconselhável que
tenha partido camada de regras de negócio.
20
2.2 Implementação de regras na Camada de Negócio
As regras de negócio definem ou restringe uma determinada funcionalidade

do sistema, esta camada tem por objetivo proporcionar fácil entendimento das regras,
além de possibilitar que as sejam utilizadas de qualquer lugar do software.
Regras de negócios devem suportar a avaliação das estruturas de uma lingua-

gem de regras correspondente afirma (HAY; HEALY, 1997). Sua principal funcionalidade
é gerenciar uma coleção de regras e avaliar os conjuntos de predicados de uma requi-
sição, devem ter a capacidade compreender um grande número de fatores e avaliar
eficientemente predicados.
Com base nas definições de regras de negócios, (SANTOS, 2014) afirma que
as linguagens de programação fornecem algum mecanismo de mapeamento para gerar
código de execução de nível mais baixo, geralmente classes de linguagem de uso geral.
Essas classes podem ser usadas como uma implementação parcial de um componente
de negócios maior. Uma consequência imediata desta abordagem é que o ciclo de
vida de implementação das regras de negócios está alinhado com o ciclo de vida do
componente de negócios ao qual elas pertencem.
Desta forma é possível constatar que flexibilidade das implementações de

regras de negócio se dá através do suporte de manutenção de regras permitindo
mudanças dinâmicas. Essa capacidade permite, de maneira simples, modificar dinami-
camente as regras de negócios sem reconstruir ou reimplantar a implementação para
se adaptar rapidamente aos ambientes de negócios em caso de mudança.
Em sistemas de n camadas bem elaborados as regras definem a execução do

próprio processo de negócios, e neste caso, é necessário considerar sua complexidade
e frequência de mudança. Os processos de negócios geralmente oferecem recursos
para avaliar regras simples, construídas na linguagem de processos de negócios ou
por invocação de linguagens de uso geral. Assim, é perfeitamente viável implementar
regras de negócios "simples"no mecanismo de processos de negócios. Neste caso,
no entanto, qualquer alteração nas regras irá exigir um teste completo e implantação
do processo de negócios. Quanto às regras de negócios complexas, elas geralmente
precisam ser extraídas do processo e implementadas como um serviço separado,
usando um mecanismo de regras.
Outro cenário típico é aquele em que o próprio processo de negócio (estrutura

de processo) é bastante estável, entretanto, as regras que regem as transições de
atividades, embora bastante simples, podem mudar frequentemente. Nesse caso, a
implementação de regras de externalização com serviços separados, implementados
usando um mecanismo de regras pode melhorar significativamente a manutenção
21
geral da solução. A capacidade dos sistemas de suportar mudanças dinâmicas nas

regras de negócios permite modificar a implementação de processos de negócios sem
a necessidade de alterar e reimplantá-lo.
As regra por vezes podem ser claras, no entanto, em alguns casos podem
ambíguas, e segundo (HAY; HEALY, 1997) na maioria das vezes, contêm mais de uma
ideia, e claramente não fazem nem sempre são originadas de uma análise profunda.
No artigo de (HAY; HEALY, 1997) é possível entender que o processo de

identificação de regras de negócios é muitas vezes iterativo e heurístico, onde as regras
começam como declarações gerais de política de negócio. Mesmo que a política seja
formal e específica, ela é tipicamente descrita em uma forma geral e informal.
2.3 Implementação de regras na Camada de Dados
A ideia é que a camada de serviço disponibilize uma Application Programming

Interface, API, limpa para a interface do usuário que, levando em consideração, a
implementação multicamadas, não necessita conhecer a implementação da camada
de negócio. Já a camada de banco de dados, mantem todos os dados necessários
para a camada de serviço.
(DATE, 2011) afirma que as regras de negócio normalmente são implementadas

na camada de mesmo nome. No entanto o uso dos Sistemas Gerenciadores de
Banco de Dados possibilitou a utilização de algumas funcionalidades nativas da maior
parte dos SGBD’s como, visões (views), os gatilhos (trigger’s), funções (functions) e
procedimentos (stored procedures).
Os SGBDs atuais oferecem diversos recursos que facilitam as tarefas

de manipulação de dados e, consequentemente, o gerenciamento de
um banco de dados. Dentre os principais recursos, que não são tão
inovadores, mas que possuem uma importância gigantesca no trabalho
de um DBA podemos citar as stored procedures, views e triggers (DIAS-
NETO, 2010).
Conceitualmente a utilização de qualquer destes recursos é, de fato, uma

implementação de regras de negócio na camada de dados, tendo em vista que no
momento da criação de uma trigger, por exemplo, deve passada um conjunto de
informações, regras, que devem ser seguidos para sua execução.
O autor (KROSING; MLODGENSKI, 2013, p. 97) defende qe embora seja uma

boa prática manter o código relacionado em conjunto e evitar ações "ocultas"como
parte dos principais fluxos de código de aplicação, podem ocorrer casos em que é uma
boa prática adicionar algum tipo de funcionalidade geral ou de aplicação cruzada ao
22
Banco de dados usando ações automatizadas que ocorrem cada vez que uma tabela é
modificada. Ou seja, as ações ou regras tornam-se parte do modelo de dados e não
o código da sua sua camada de regra de negócio. O mesmo autor afirma que não é
possível ignorar este tipo de implementação. Tendo em vista que em alguma momento
analistas ou gerentes de bancos de dados irão ter esta necessidade.
Em outro ponto (KROSING; MLODGENSKI, 2013) uma das funcionalidades,

disponiveis em no Postgresql, para adicionar chamadas de função automatizada para
um evento de modificação de tabela é chamada de gatilho. Os disparadores são
especialmente úteis para casos em que existem várias aplicações de clientes diferentes
- possivelmente de diferentes fontes e usando diferentes estilos de programação -
acessando os mesmos dados usando várias funções diferentes ou SQL direto
Seguindo este mesmo linha de pensamento (DATE, 2011) afirma que é possível
afirmar a grande maioria dos os sistema vinculados a um SGBD, utilizam regras
vinculadas à camada de dados, tendo em vista que todos os softwares se utilizam de
views, trigger’s ou functions. Pode se dizer que isso é prática inerente aos sistemas de
informação modernos.
2.3.1 PostgreSQL e as Regras de Negócio
Para empresas que possuem sistemas de informação, os dados armazenados

são de suma importância para o funcionamento das suas atividades. Neste sentido as
regras de negócio estão diretamente ligadas a estes dados. Muitas empresas entendem
sua base de dados como o seu bem mais valioso.
Conforme (MARR, 2015), as empresas acumulam vastas quantidades de dados

que não têm nenhuma ideia do que fazer com eles. Assim o volume de informações
armazenadas em SGBDS vai aumentando de forma significativa.
Técnicas de programação em bancos de dados já existem há muito

tempo, mas com o aumento do uso das redes, volume de informações e
necessidade de desempenho nas aplicações, sua utilização mostra-se
como uma solução alternativa para melhoras no desenvolvimento de
sistemas.(PADOIN; JUNIOR; DILL, 2008)
Ainda de acordo com (MARR, 2015), é importante lembrar que a coleta e o

armazenamento de dados custa dinheiro, tendo em vista que as estruturas necessárias
para o armazenamento tem um alto valor manutenção, além disso, se a informação é
crítica, como por exemplo registros de clientes o gasto pode ser ainda maior, levando
em conta a segurança que deve ser prevista para mandar determinados tipos de dados..
23
Além destes argumentos, há que se levar em consideração que o volume de

dados gerados cresce em um volume muito alto. (MARR, 2015) fala que pode haver
um aumento de 4.300 por cento na produção de dados anual até 2020.
O problema pode se tornar ainda maior quando levamos em conside-

ração o crescimento previsto nas empresas de dados que produzirão:
Estão prevendo um aumento de 4,300 por cento na produção anual de
dados até 2020. Em média, as empresas usam apenas uma fração dos
dados que coletam e armazenam. Em suma, se uma empresa já está
lutando para armazenar e analisar seus próprios dados agora, estará
se afogando nos dados nos próximos anos.(MARR, 2015)
Estas informações nos levam a crer que, ao aumentar o volume de dados, as

regras que envolvem estes dados tendem ter sua complexidade aumentada na mesma
escala. Isso é reforçada pelo fato de o PostgreSQL aumentar seu foco em regras,
tanto que em suas em suas ultimas atualizações, mais precisamente na versão 9.2, foi
disponibilizado o The Rule System, ou O Sistema de Regras, conforme especificado
em (POSTGRESQL, 2012).
O sistema de regras de reescrita de consulta é totalmente diferente

dos procedimentos e disparadores armazenados. Ele modifica as con-
sultas para levar em consideração as regras e, em seguida, passa a
consulta modificada para o planejador da consulta para planejamento e
execução.(POSTGRESQL, 2012)
Em outras palavras, podemos dizer que o sistema criado na versão 9.2 do

PostgresSQL tem por objetivo modificar as consultas para levar em consideração as
regras, e posteriormente passar para o planejamento da execução, e após é executado.
É na prática mais uma ferramenta de centralização de regras.
2.3.2 Funções definidas pelo usuário
As funções definidas pelo usuário, em inglês User defined functions (UDF),

tem a funcionalidade de permitir que uma consulta seja cadastra com um ou mais
parâmetros de entrada e saída, permitindo o reúso sem a reescrita. Estes tipos de
função permitem a reutilização de código escrito. Portanto, uma vez criada você pode
reutilizá-la quantas vezes quiser.
24
Uma função definida pelo usuário é uma extensão ou adição às funções

internas existentes da linguagem SQL. Com UDFs, é permitido que você
estenda a função do sistema de banco de dados, incluindo definições
de funções a serem aplicadas no mecanismo do banco de dados. Ao
incluir a função no mecanismo, você poderá economizar o esforço de
recuperar linhas do banco de dados e aplicar funções semelhantes nos
dados recuperados. Funções definidas pelo usuário permitem que o
banco de dados explore as mesmas funções do mecanismo utilizadas
pelos aplicativos. Elas fornecem mais sinergia entre o aplicativo e o
banco de dados. Elas também contribuem com a alta produtividade
para desenvolvedores de aplicativos, pois elas incentivam a reutilização
de códigos. Como exemplo, pode-se criar uma simples função definida
pelo o usuário que retorne o primeiro nome do cliente em uma tabela
aonde só possui o nome completo (PADOIN; JUNIOR; DILL, 2008).
As UDF’s podem ser executadas por outras consultas sem ter que escrever
todo SQL novamente. Para executar o código da UDF é necessário fazer uma chamada
para a função com o seu nome e todos os parâmetros entre parênteses. O uso de
funções também tornam o código mais claro, podem reduzir a duplicação de linhas e
regras que podem atrapalhar a compreensão de um script.
2.3.3 Stored Procedures
Assim como as UDF’s, um procedimento armazenado é um script SQL, ar-

mazenado no banco de dados, para que ele possa ser utilizado por outros SQL’s ou
chamadas(CALL). Conforme (PADOIN; JUNIOR; DILL, 2008), procedimento encapsula
tarefas repetitivas, aceita parâmetros de entrada e retorna um valor de status (para
indicar aceitação ou falha na execução).
Um aplicativo cliente pode, então, simplesmente chamar os procedi-

mentos armazenados para obter resultados das instruções SQL que
estão contidas no procedimento. Devido ao procedimento armazenado
executar a instrução SQL no servidor, o desempenho do banco de
dados é melhorado. Além disso, procedimentos armazenados podem
ajudar a centralizar a lógica comercial. Se você fizer alterações em
um procedimento armazenado, as alterações tornam-se imediatamente
disponíveis para todos os aplicativos clientes que o utilizam (PADOIN;
JUNIOR; DILL, 2008).
No artigo do autor (SANTOS, 2014), ele sintetiza que Uma Stored Procedure,
é uma coleção de instruções implementadas com linguagem plSQL que depois de
armazenadas, ficam vinculadas ao SGBD de forma pré-compilada, até o momento
que que alguma aplicação ou ação faz sua execução. Assim como VIEWS fazem
com relatórios e dados estatísticos escalonáveis, os procedimentos armazenados
encapsulam tarefas repetitivas, desde uma simples inserção, passando por inserções
por lote, alterações, ou ainda como cita o mesmo autor, instruções mais complexas,
25
como, efetuar uma efetivação de saque em uma conta de um determinado cliente

em uma instituição bancária ou efetivar saídas de mercadorias seguido por baixa em
estoque. O uso de procedimentos armazenados permite controlar a inserção de dados,
preservando sua integridade e melhora a produtividade, evitando reescrita de regras.
2.3.4 Linguagem procedural para SQL
Procedural Language/Structured Query Language (PL/SQL) foi criado original-

mente pela Oracle, é considerada uma linguagem de procedimentos sendo que a maior
parte dos SGBD’s atuais implementaram tecnologias equivalentes. No entanto com
variações no nome, por exemplo, no PostgreSQL é nomeada de PL/pgSQL.
De acordo com a documentação encontrada em (POSTGRESQL, 2001), com o

PL/pgSQL, é possível agrupar um bloco de instruções a uma série de consultas dentro
do servidor de banco de dados, tendo assim o poder de uma linguagem procedural
com facilidade de uso do SQL, mas com economias consideráveis de sobrecarga de
comunicação de rede cliente/servidor.
PL/SQL aceita parâmetros de entrada e de saída, assim pode retornar os

resultados para o a chamada usando. O código PL/SQL escrito suporta um elevado
número de comandos, sendo possível, utilizar laços de repetição, operadores booleanos,
efetuar chamadas de procedimentos cadastrados, ou UDF’s.
A (FEUERSTEIN; PRIBYL, 2005) cita que PL/SQL é uma linguagem altamente

estruturado, legível e acessível, segundo ele é uma ótima linguagem para um progra-
mador novato, tendo em vista que é uma linguagem fácil de aprender e é rico com
palavras-chave e estrutura que expressam claramente a intenção do código.
3 MODELAGEM E ESTUDO DE CASO
Este capítulo tem por objetivo aprofundar e exemplificar a implementação de

Regras de Negócio no Sistema de Gerenciamento de Banco de Dados, abordando ainda
formas de implementações de regras com linguagem procedural PostgreSQL PL/pgSQL,
utilizada para programação de funções, gatilhos, procedimentos armazenados, entre
outros métodos de implementação de regras de negócio.
3.1 A Linguagem de Programação
Para o desenvolvimento do aplicativo, será utilizado o Delphi Starter. O Delphi

é um Ambiente de Desenvolvimento Itegrado, IDE, desenvolvido pela Embarcadero. É
considerado uma ferramenta de desenvolvimento rápido, RAD. O Delphi é totalmente
orientado a objetos, com dois compiladores, possibilitando programar em C++ e Object
Pascal, sendo que a ultima foi escolhida como linguagem de programação para o
aplicação das pesquisas realizadas no decorrer deste trabalho.
O Data Explorer possibilita que desenvolvedores naveguem rapida-

mente por tabelas de bancos de dados, visualizações, procedimentos
armazenados e funções - tudo isso diretamente do RAD Studio IDE.
Usando o Navegador de dados, é possível ver e editar rapidamente
seus dados em tempo real, além de criar e alterar tabelas de bancos de
dados compatíveis. O Data Explorer também permite que você arraste e
solte dados diretamente em seu projeto, adicionando automaticamente
a conexão de banco de dados e consulta para utilização em seu código.
(EMBARCADERO, 2016)
Com o Delphi o desenvolvimento se torna mais rápido, pois permite que regras
implementadas no SGBD sejam executadas de forma rápida e facilitada. O Delphi pos-
sibilita um nível de abstração elevado, o que contribui para o aumento de produtividade
do desenvolvimento de software.
3.2 Modelo de Dados
O modelo de dados elaborado no decorrer do estudo do trabalho, destina-se

ao desenvolvimento de um sistema de informação genérico voltado para assistências
técnicas em geral. O sistema inclui cadastro de pessoas, usuários, técnicos, clientes,
endereços e todo o controle necessário para o gerenciamento de ordens de serviço
(OS).
27
Figura 4 – Base de Dados
Fonte: Próprio Autor
O modelo de dados é um tipo de abstração de dados usado para

prover essa representação conceitual. O modelo de dados utiliza os
conceitos lógicos, como objetos, suas propriedades e seus interrelacio-
namentos, que podem ser mais fáceis para os usuários entenderem os
conceitos de armazenamento computacionais. Consequentemente, o
modelo de dados esconde os detalhes de armazenamento e da imple-
mentação, desinteressantes para a maioria dos usuários de banco de
dados.(ELMASRI et al., 2005)
3.3 A linguagem SQL
Considerando que o modelo de dados foi concebido seguindo as boas praticas

de modelagem de dados, pode-se citar aqui como exemplos generalização, agregação
e integridade referencial, é possível afirmar que uma regra bem implementada no SGBD
permite abstrair e simplificar todo o trabalho da camada de regras de negócio. Não
obstante disso, a simplicidade da implementação de regras de negócio em PostgreSQL
é uma motivação adicional para o uso desta técnica.
Desta forma é importante salientar que se trata de uma questão de definição

de escopo de implementação. Ou seja, quais serão as regras que poderão ir para o
28
SGBD, tendo em vista que, o objetivo não é eliminar a camada de regra de negócio
e sim estender parte das regras para o SGBD. No entanto, isso deve ser feito com
controle e em casos específicos.
A simplicidade de implementação de regras na de base de dados, também

se deve ao fato de que não é necessário conhecer outras linguagens de programa-
ção, tendo em vista que PL/pgSQL é cem por cento SQL e isso faz com que ocorra
diminuição do tempo de desenvolvimento.
Em resumo, os regras em SGBD’s permitem alavancar o tempo de construção

da implementação das regras de negócio, pois as linguagens PL/pgSQL e SQL, são
menos verbosas que a maior parte das linguagens de programação.
3.4 Visões
Uma visão é um objeto de dados que não contém dados, ou seja, o conteúdo
da visão é resultante de uma tabela de base, as views, são representações não
materializadas de uma entidade do banco de dados.
A diferença entre uma visão e uma tabela é que as as visões são definições
construídas em cima de outras tabelas. Se os dados forem alterados na tabela de
origem, a mesma alteração será refletida na view. Uma visão pode ser construída em
cima de uma ou várias tabelas.
Uma visão, na terminologia SQL, é uma tabela única derivada de outra

tabela, que pode ser uma tabela básica ou uma visão previamente
definida. Uma visão não existe de forma física, ela é considerada uma
tabela virtual, em contraste com as tabelas básicas, cujas tuplas são
realmente armazenadas no banco de dados. Isso limita as operações
de atualização possíveis para as visões, embora não imponha nenhuma
limitação para as consultas.(ELMASRI et al., 2005)
Figura 5 – Estrutura de uma View
1 CREATE [ OR REPLACE ]
2 [ TEMP | TEMPORARY ]
3 [ RECURSIVE ]
4 VIEW name [ ( column_name [ , ...] ) ]
5 [ WITH ( view_option_name [= view _optio n_valu e ] [ , ... ] ) ] AS
query

29
Figura 6 – Exemplo de uma View composta
1 CREATE OR REPLACE VIEW v_get_dados_os as

2 select p . nome ,
3 p . cpf_cnpj ,
4 os . id_ordem_servico ,
5 s . descricao ,
6 TO_CHAR ( a . dt_alteracao , ’ DD / MM / YYYY ’)
7 from pessoas p
8 join clientes c on
9 ( c . id_pessoa = p . id_pessoa )
10 join ordens_servico os on
11 ( os . id_cliente = c . id_cliente )
12 join alteracoes_os a on
13 ( a . id_ordem_servico = os . id_ordem_servico )
14 join situacoes_os s on
15 ( s . id_situacao = a . id_situacao )
16 order by cod_os ,
17 s . id_situacao desc
A figura 5 define a estrutura de uma visão não materializada de uma consulta,

já a figura 6 é representa a criação de uma view que tem composição de mais de uma
tabela. .
3.5 Funções Armazenadas SQL
Funções Armazenadas SQL, permitem o agrupamento de consultas SQL,

diminuindo o congestionamento de rede entre os bancos de dados e os servidores de
aplicações. Proporciona também, vantagens adicionais, como permitir incluir estruturas
condicionais e iterativos, herdar regras de outras funções, aumentar o desempenho
em cálculos. Além do aumento da velocidade de implementação, diante disso ao
implementar a regra em uma Função Armazenada SQL ocorre automaticamente uma
redução de escrita de código na camada de regra de negócio.
As funções, são utilizadas para executar operações com base em alguma

regra e retornarem um ou mais dados, possibilita o reuso e promove facilidade na
manutenção, pode ser chamada a partir de, trigger, outras functions e instruções SQL.
A figura 7 representa a estrutura de uma Função Armazenada que é dividida

em declaração, onde é definido o seu nome e os argumentos de entrada, chamados
também de parâmetros, posteriormente o tipo de retorno, que pode ser apenas um
dado ou uma tabela, como pode ser visto na figura 8, e posteriormente as informações
que resultarão no retorno da tabela.
30
Figura 7 – Estrutura de uma Função Armazenada
1 CREATE [ OR REPLACE ] FUNCTION

2 name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = }
default_expr ] [ , ...] ] )
3 [ RETURNS rettype
4 | RETURNS TABLE ( column_name column_type [ , ...] ) ]
5 { LANGUAGE lang_name
6 | WINDOW
7 | IMMUTABLE | STABLE | VOLATILE
8 | CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
9 | [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY
DEFINER
10 | COST execution_cost
11 | ROWS result_rows
12 | SET c o n f i g u r a t i o n _ p a r a m e t e r { TO value | = value | FROM
CURRENT }
13 | AS ’ definition ’
14 | AS ’ obj_file ’ , ’ link_symbol ’
15 } ...
16 [ WITH ( attribute [ , ...] ) ]
A execução da estrutura da função da figura 8, é feita conforme demonstrado

na figura 9, desta forma obtem-se como resultado os dados que se adequarem a regra
implementada na função da figura 8.
Tabela 1 – Resultado da Execução

nome cpf_cnpf os descricao data_alteracao
Brett Benton 1604021645899 201 ORÇADO 31/03/2018
Brett Benton 1604021645899 201 CONSERTADO 06/01/2018
Eric Pace 1610112032099 203 ORÇAMENTO 05/10/2016
Brandon Frederick 1684060953599 303 ORÇAMENTO 25/03/2017
Drake Webb 1616090291299 304 SEM CONSERTO 09/05/2018
Grady Weeks 1617042334899 204 ORÇADO 14/06/2017
Amery Pearson 1620122438499 205 SEM CONSERTO 22/07/2016
Amery Pearson 1620122438499 205 CONSERTADO 13/08/2017
Marsden Huffman 1692091365499 306 SEM CONSERTO 02/03/2017
Marsden Huffman 1692091365499 306 CONSERTADO 23/09/2016
Ainda é possível adicionar clausulas na chamada da função, desta forma

além das regras já implementadas, outras regras podem ser adicionadas, conforme é
representado na lista 10, onde se tem o objetivo de retornar apenas a ordem de serviço
de número 201.
Coforme o autor (KROSING; MLODGENSKI, 2013), se a lógica por trás da

função precisar mudar, basta alterar a função sem tempo de inatividade e não é
31
Figura 8 – Função Armazenada do tipo tabela
1 CREATE OR REPLACE FUNCTION get_dados_os ()

2 RETURNS TABLE (
3 nome varchar ,
4 cpf_cnpf char ,
5 os integer ,
6 descricao varchar ,
7 data_alteracao char )
8 AS
9 $$
10 select p . nome ,
11 p . cpf_cnpj ,
13 s . descricao ,
15 from pessoas p
26 $$
27 LANGUAGE ’ sql ’ VOLATILE ;
Figura 9 – Execução da função
1 SELECT *
2 FROM get_dados_os () ;
Figura 10 – Execução da função
1 SELECT *
2 FROM get_dados_os ()
3 where os = 201;
necessária nenhuma organização complicada para efetuar atualizações de consulta de

banco de dados. Uma vez que a função é alterada no banco de dados, ela é alterada
para todos os usuários.
32
Fica perceptível que uma função ou uma visão tem muitas semelhanças,
no entanto, alguns recursos podem ser adicionados a uma função, melhorando seu
desempenho, o que não ocorre em uma View.
Na figura 11 fica evidente a diferença entre a uma Function e uma View, tendo
em vista que dependendo do tipo de implementação o desempenho da Function será
muito melhor do que em relação a View.
Figura 11 – Criação da função
1 CREATE OR REPLACE FUNCTION get_dados_por_os ( IDOS integer )

2 RETURNS TABLE (
3 nome varchar ,
4 cpf_cnpf char ,
5 os integer ,
6 descricao varchar ,
7 data_alteracao char )
8 AS
9 $$
10 select p . nome ,
11 p . cpf_cnpj ,
13 s . descricao ,
15 from pessoas p
24 where os . id_ordem_servico = idos
27 $$
28 LANGUAGE ’ sql ’ VOLATILE ;

33
Ao analisar a implementação da regra da função da figura 8, pode-se concluir

que, toda a regra implementada tem vínculo com 5 entidades do banco de dados,
a saber, pessoas, clientes, ordens_servico, alteracoes_os e situacoes_os. Se com-
pararmos a uma implementação utilizando orientação a objetos, poderíamos chegar
ao mesmo resultado fazendo a relação com 5 classes. Isso obviamente aumentaria
consideravelmente o trafego de rede, além de aumentar a complexidade de escrita de
código.
3.6 Procedimentos Armazenados
Assim como a Function, Stored Procedure, ou procedimento armazenado,

permite executar um conjunto de operações com base em alguma regra, a diferença
principal é que não há necessidade de retornar algo, e seu principal objetivo é encapsu-
lar tarefas repetitivas. Pode aceitar parâmetros de entrada e retorna um valor de status.
A Stored Procedure reduz o tráfego na rede, melhora a performance, cria mecanismos
de segurança.
Figura 12 – Criação da função
1 CREATE OR REPLACE FUNCTION i n s e r e _ a l t e r a c o e s _ o s

2 ( dt_alteracao date ,
3 hr_alteracao timestamp ,
4 id_usuario integer ,
5 id_ordem_servico integer ,
6 id_situacao integer ,
7 id_tecnico integer )
8 returns void as
9 $$
10 begin
11 INSERT INTO alteracoes_os
12 values ( Nextval ,
13 dt_alteracao ,
14 hr_alteracao ,
15 id_usuario ,
16 id_ordem_servico ,
17 id_situacao ,
18 id_tecnico ) ;
19 end ;
20 $$ LANGUAGE ’ plpgsql ’;
Fica evidente que este tipo de implementação permite que a camada de regras
de negócio fique mais simples, e consequentemente mais organizada.
34
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 necessá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. (PEREIRA, 2008).
Stored Procedure permitem ainda que outras implementações seja feitas, por
vezes, regras muito complexas do ponto de vista da orientação a objetos podem se
tornar simples em uma implementação no banco de dados.
3.7 Gatilhos de Procedimentos
Outra funcionalidade existente nos SGBDS, são as Triggers, ou Trigers Proce-

dures, como o proprio nome já identifica, são gatilhos que são acionador com base em
alguma regra e executam alguma ação na base de dados.
Estas execuções ocorrem com base em alguma ação feita em tabela ou registro
como por exemplo, um insert, delete ou update. A trigger está relacionada a uma
entidade, ao executar uma destas ações é possível dispará-lo para executar alguma
tarefa.
As Triggers são definidas para atuar antes ou depois de um insert, update ou

delete, ou que sejam executadas em determinados horários ou ainda para que o valor
de um determinado campo for alterado.
Figura 13 – Criação do Gatilho
1 CREATE TRIGGER nome { BEFORE | AFTER }

2 { INSERT | UPDATE | DELETE [ OR ... ] }
3 ON tabela [ FOR [ EACH ] { ROW | STATEMENT } ]
4 EXECUTE PROCEDURE nome_funcion ( argumentos )
O processo de criação de uma trigger consiste em, primeiramente criar uma

função que faça o desejado, após isso criar a trigger, que será, de certa forma um
monitor de tabela, que quando a ação esperada for executada na tabela, a trigger
executará a função criada anteriormente.
Os gatilhos podem retornar valores nulos para indicar que não realizaram
nenhuma atualização e que o resto da operação deve ser ignorada. Caso haja outras
Triggers, estas não serão disparadas. Caso contrário, um valor não nulo pode ser
retornado, para indicar que o gatilho executou a operação solicitada.
4 IMPLEMENTAÇÃO DO ESTUDO DE
CASO
O presente capítulo trata da implementação de uma regra de negócio com nível

de complexidade elevada, utilizando, conforme delimitado nos capítulos anteriores da
pesquisa, a versão 9.6 do PostgreSQL, a versão Starter do Delphi e massa de dados
fictícia, gerada em (GENERATEDATA.COM, 2016), para popular as tabelas do modelo
de dados.
4.1 Delimitação da Implementação
O objetivo de tal implementação consiste, especificamente, em construir uma

regra de negócio que tem por finalidade, inserir uma ocorrência de alteração na tabela
ALTERACOES_OS sempre que ocorrer alguma mudança de situação de uma ordem
de serviço. As ocorrências inseridas tem por finalidade manter o histórico de cada
ordem de serviço.
4.2 A implementação
O modelo relacional do banco de dados foi apresentado na 4, sendo que, de

acordo com a delimitação a implementação proposta atuará nas entidades que seguem.
• Ordens_Servico
• Alteracoes_OS
• Situacoes_OS
Na figura 14 é evidenciado parte do modelo de dados representado na 4. Desta

forma é possível verificar que existe uma relação de 1 para N, ou seja para cada
registro na tabela "ORDENS_SERVICO", existem, N registros na entidade relacional
"ALTERACOES_OS", da mesma forma que para cada registro existente na tabela
SITUAÇOES_OS podem existir N registros na entidade "ALTERACOES_OS".
36
Figura 14 – Recorte da figura 4
Neste sentido se apresenta a implementação da regra de negócio. Ao dese-

nhar a tela de um software de computador que irá gerenciar as ordens de serviço, ou
seja fazer inserção, alterações ou deleções na tabela "ORDENS_SERVICO", deve ser
especificado que quando ocorrer qualquer mudança na situação de um registro na
tabela em questão, automaticamente deve ser feito um registro na tabela "ALTERA-
COES_OS", para manter o histórico de todas as movimentações feitas no registro da
ORDEM_SERVICO.
Figura 15 – Diagrama do processo utilizando ferramenta do site (BPMN.IO, 2016)
A figura 15 representa o processo de alteração de situação de ordem de serviço.

37
Este diagrama é lido da seguinte forma:
• A ordem de serviço sofreu uma alteração;
• A partir deste momento um script é iniciado;
• Resultando assim em um registro da alteração da ordem de serviço;
Tendo em vista as definições já apresentada, foi desenvolvido a aplicação,

representada na figura 16. Desta forma, é possível ter um entendimento mais adequado
de qual o tipo de regra deve ser implementada no momento das alterações ou inserções
de ordens de serviço.
Figura 16 – Tela de Ordens de Serviço
Abaixo são elencados itens para o desenvolvimento da regra de negócio que

deve ser implementada.
• O usuário está inserindo um novo registro?
• A ordem de serviço já existe e sua situação está sendo alterada?
• A ordem de serviço já existe e sua situação não está sendo alterada?

38
• A situação da ordem de serviço atual é uma situação inicial?
• A situação da ordem de serviço atual é uma situação final?
4.2.1 Tipo de Implementação escolhida
Partindo da finalidade desta aplicação, optou-se por utilizar uma Stored Proce-
dure, que aplicará a regra escrita em linguagem PL/SQL.
Perguntas relevantes para a implementação:
Quais parâmetros são necessários para concluir a inserção na tabela ALTERA-

COES_OS?
Quais as ações serão feitas pela Stored Procedure?
Uma única implementação atenderá a especificidade imposta pela regra que

se pretende implementar?
Estes questionamentos deverão ser respondidos ao final da implementação da

regra.
Figura 17 – Insert Em ALTERACOES_OS

2 VALUES ( id_alteracao_os ,
3 dt_alteracao ,
4 hr_alteracao ,
5 id_usuario ,
6 id_ordem_servico ,
7 id_situacao ,
8 id_tecnico ) ;
A figura 17, é o objetivo final, pois é esta instrução que irá inserir os dados na
tabela ALTERACOES_OS.
Figura 18 – Início da implementação da regra
1 CREATE OR REPLACE FUNCTION

2 ins e r e _ a l t e r a c o e s _ o s ( id_usuario integer ,
3 id_ordem_servico integer ,
4 id_situacao integer ) ;

39
A figura 18 é o início da construção da regra, nesta etapa é feita a definição

dos parâmetros de entrada. Neste caso foram definidos para a execução da Stored
Procedure os seguintes dados: ID_USUARIO, ID_ORDEM_SERVICO e ID_SITUACAO.
Vale aqui ressaltar que para poder efetuar a inserção na tabela ALTERA-
COES_OS, são necessários as seguintes informações: ID_ALTERACAO,
DT_ALTERACAO, HR_ALTERACAO, ID_USUARIO, ID_ORDEM_SERVICO,
ID_SITUACAO, ID_TECNICO.
Demonstrando assim que a aplicação cliente não conhecerá as regras imple-

mentadas, pois a Stored Procedure que está sendo implementada espera receber
apenas três argumentos de entrada, enquanto a inserção que estará contida na Stored
Procedure precisa receber sete parâmetros, conforme está evidenciado na figura 19.
Figura 19 – Implementação da regra de negócio
1 CREATE OR REPLACE FUNCTION i n s e r e _ a l t e r a c o e s _ o s ( idusuario

integer ,
2 idordeservico integer ,
3 idsituacao integer )
4 RETURNS void AS
5 $BODY$
6 begin
8 values ( Nextval ,
9 current_date ,
10 current_time ,
11 idusuario ,
12 idordeservico ,
13 idsituacao ,
14 ( select id_usuario
15 from tecnicos
16 where id_usuario = idusuario )
17 );
18 end ;
19 $BODY$
20 LANGUAGE plpgsql VOLATILE ;
É possível observar na figura 19, os atributos "ID_ALTERACAO", "DT_ALTERACAO"e

"HR_ALTERACAO", contidos no na lista 17, foram substituídos por NextVal, cur-
rent_date, current_time, respectivamente, estas substituições são possíveis pois o
PostgreSQL disponibiliza tais funcionalidades e cada uma com um objetivo distinto
conforme segue:
• NextVal: retorna o próximo valor inteiro do atributo.

40
• current_date: retorna data atual.
• current_time: retorna hora atual.
Assim sendo estes atributos da entidade não precisam ser informados no

momento do inserção, eles serão gerados automaticamente sob a responsabilidade do
SGBD. Algo parecido ocorre com o atributo ID_TECNICO, entretanto para este caso
foi implementado um subselect que retorna o ID_TECNICO da entidade TECNICOS,
presente no modelo de dados, figura 4, esta rotina recebe O ID_USUARIO e caso este
tenha registros na tabela TECNICOS, seu identificador será retornado.
Com o script apresentado na figura 19 atendemos os requisitos da implemen-

tação da regra, sendo que a aplicação cliente apenas repassará parte dos dados
necessários para a inserção, o restante está contido nas regras da Stored Procedure.
No entanto, o resultado pode ser melhorado, na medida em que a regra criada

tem retorno VOID, isto quer dizer, não retorna informações. Analisando a implementação
na aplicação, 16, será adicionada à Stored Procerure o retorno dos registros da entidade
ALTERACOES_OS, tendo como base o SQL do script da figura 20.
Figura 20 – Consulta adicional para a regra de negócio
1 select a . dt_alteracao ,
2 s . descricao ,
3 p . nome
4 from alteracoes_os a ,
5 situacoes_os s ,
6 usuarios u ,
7 pessoas p
8 where a . id_situacao = s . id_situacao and
9 a . id_usuario = u . id_usuario and
10 u . id_pessoa = p . id_pessoa and
11 a . id_ordem_servico = 123
12 order by dt_alteracao desc ;
Desta forma, executando algumas modificações no procedimentos armazenado

desenvolvido anteriormente, aumenta a complexidade da regra implementada, no
entanto a complexidade da implementação diminui, tendo em vista que no momento
que a Stored Procedure for executada, o seu resultado será o conjunto de informações
já tabulados e prontos para serem apresentados na aplicação cliente.
Na figura 21, é adicionada a regra conforme citado anteriormente, porém cabe

ressaltar que, para modificar o tipo de retorno de uma Stored Procedure no PostgreSQL
versão 9.6, não basta o comando CREATE FUNCTION, nestas situações, é necessário
41
executar o comando DROP FUNCTION. Desta forma, o SGBD apaga o registro da

Stored Procedure tornando assim possível a alteração do tipo de retorno. Vale ressaltar
que neste caso o tipo de utilizado é do tipo TABLE, já abordado no capitulo 3 do
trabalho.
Figura 21 – Implementação da completa da regra de negócio
1 DROP FUNCTION i n s e r e _ a l t e r a c o e s _ o s ( idusuario integer ,

idordeservico integer , idsituacao integer ) ;
2
3 CREATE FUNCTION i n s e r e _ a l t e r a c o e s _ o s ( idusuario integer ,
4 idordeservico integer ,
5 idsituacao integer )
6 RETURNS TABLE ( dt_alteracao date , descricao character , nome
character ) AS
7 $BODY$
8 begin
9 INSERT INTO alteracoes_os values ( Nextval ,
10 current_date ,
11 current_time ,
12 idusuario ,
13 idordeservico ,
14 idsituacao ,
15 ( select id_usuario
16 from tecnicos
17 where id_usuario = idusuario ) ) ;
18 select a . dt_alteracao ,
19 s . descricao ,
20 p . nome
21 from alteracoes_os a ,
22 situacoes_os s ,
23 usuarios u ,
24 pessoas p
25 where a . id_situacao = s . id_situacao and
26 a . id_usuario = u . id_usuario and
27 u . id_pessoa = p . id_pessoa and
28 a . id_ordem_servico = idordeservico
29 order by dt_alteracao desc ;
30 end ;
31 $BODY$
32 LANGUAGE plpgsql VOLATILE ;
É possível identificar na figura 22 que a Stored Procedure foi criada com

sucesso. Além disso, o escopo delimitado no início deste capítulo foi atingido, pois a
implementação atende todos os objetivos, foi construída de forma coerente, clara com
nível elevado de abstração para outras camadas do sistema.
Ao chegar neste ponto os três questionamentos iniciais foram respondidos. As

42
Figura 22 – Estrutura do Catalogo
implementações de regras PostgreSQL possibilitam definir uma ação alternativa a ser

executada em inserções, atualizações ou exclusões em tabelas de banco de dados.
Em termos gerais, a regra faz com que comandos adicionais sejam executados quando
um determinado comando em uma determinada tabela é acionado.
4.3 Resultados Obtidos
Diante do exposto, no decorrer da pesquisa, foi possível aprofundar os conheci-

mentos em regras de negócio em banco de dados, o que possibilitou a implementação
da regra neste subcapítulo. Desta forma, é exequível que os resultados encontrados
são satisfatórios, pois atendem as especificidades do escopo do problema.
Faz-se necessário salientar que a implementação da regras na camada de

43
dados em PostgreSQL, para este caso, atinge os objetivos propostos no decorrer do

trabalho, principalmente as várias formas possíveis de implementação de regras no
PostgreSQL.
Desta modo pode ser afirmado que a implementação feita no presente capítulo,
é plenamente plausível em um ambiente empresarial, onde exista esta necessidade,
pois é genérica e pode atender a grandes volumes de dados.
5 CONCLUSÕES
Diante dos pontos apresentados no decorrer do trabalho de conclusão de curso,

acredita-se que a implementação de regras de negócio no PostgreSQL é plenamente
possível. Além disso é perceptível que há uma tendencia de os SGBD’s em disponibilizar
funcionalidades para este tipo de implementação na camada de dados.
Da mesma forma, é necessário avaliar o contra ponto, ou seja, de acordo o

modelo N camadas é necessário que haja uma divisão clara e definida entre cada uma
das camadas de apresentação, regra de negócio e dados, no entanto isso não quer
dizer que é expressamente proibido ter implementações de regras na camada de dados
para atender uma finalidade específica na camada de dados.
Conforme identificado no capítulo dois, e posteriormente aprofundado nos

capítulos três e quatro, existem várias metodologias de implementações de regras de
negócio em SGBD, desta forma o que deve prevalecer é o bom senso no momento da
análise.
Diante disso, a possibilidade de implementação de regras de negócio em

SGBD’s, pode proporcionar novas possibilidade à quem faz uso desta técnica, e aqui
podemos citar dois exemplos de melhorias encontradas, velocidade de desenvolvimento
e abstração de regras.
Conforme os capítulos anteriores, a velocidade de desenvolvimento é aumen-

tada, ao utilizar-se de regra de negócio no SGBD, pelo fato de que a linguagem SQL é
menos verbosa do que a maioria das linguagens, tornando assim a escrita de regra,
funções, algoritmos muito mais rápida.
Assim sendo, conclui-se que a presente pesquisa é valiosa pelo fato de que
trada de um tema pouco abordado de forma objetiva, além disso, apresenta relevante
embasamento teórico, aliado a análise e implementação em um cenário real.
A presente pesquisa permite melhorias, não sendo uma obra finita principal-
mente porque o tema não é limitado. Desta forma não há verdades absolutas, pois cada
cenário, seja ele hipotético ou real, sempre será possível identificar pontos positivos e
pontos negativos.
Assim sendo, para trabalhos futuros, seria interessante traçar um paralelo entre
as implementações de regras de negócio no banco de dados e na camada de dados,
utilizando ferramentas de benchmark, para medir desempenho, cabendo ainda análises
de trafego de rede e métricas de tempo de implementações de regras de negócio.
REFERÊNCIAS
BATTISTI, J. Criando aplicações em 3, 4 ou n camadas. Endereço Eletrô-

nico:<http://www. juliobattisti. com. br/artigos/ti/ncamadas. asp>Acesso em
07$maio.2016, 2003.
BPMN.IO. Site web-based tooling for bpmn, dmn and cmmn. Endereço
eletrônico:<https://bpmn.io/>Acesso em 02$jun.2017, 2016.
DATE, C. J. SQL and relational theory: how to write accurate SQL code. [S.l.]: "O’Reilly
Media, Inc.", 2011.
DIAS-NETO, A. C. Utilizando stored procedures, views e triggers no mysql. Endereço

eletrônico:<http://www.devmedia.com.br/utilizando-stored-procedures-views-e-
triggers-no-mysql/16471> Acesso em 25$maio.2016, 2010.
ELMASRI, R. et al. Sistemas de banco de dados. Pearson Addison Wesley, 2005.
EMBARCADERO. Deplhi starter. Endereço

eletrônico:<https://www.embarcadero.com/br/products/delphi/starter/promotional-
download>Acesso em 02$jun.2017, 2016.
ENGINES, D. DB-Engines ranking. 2013.
FEUERSTEIN, S.; PRIBYL, B. Oracle pl/sql Programming. [S.l.]: "O’Reilly Media, Inc.",
2005.
GENERATEDATA.COM. Site genarate data. Endereço eletrô-

nico:<http://www.generatedata.com>Acesso em 02$jun.2017, 2016.
GUARINO, J. Sistemas Integrados De Gestão: Desafio À Competência. [S.l.]:

Simplíssimo, 2015. ISBN 9788582450604.
HAY, D.; HEALY, K. A. Guide business rules project, final report-revision 1.2. GUIDE
International Corporation, Chicago, 1997.
KROSING, H.; MLODGENSKI, J. PostgreSQL Server Programming. [S.l.]: Packt

Publishing Ltd, 2013.
MARR, B. Big data overload: Why most companies can’t deal with the data explosion.
Forbes Magazine, 2015.
MICROSOFT, C. Developing with business rules. Endereço

eletrônico:<https://msdn.microsoft.com/en-us/library/ee268161(v=bts.10).aspx> Acesso
em 07$maio.2016, 2004.
PADOIN, E. L.; JUNIOR, J. C. B.; DILL, S. L. Programação em banco de dados:

técnicas de utilização. Anais SULCOMP, v. 2, 2008.
46
PEREIRA, P. S. Artigo sql magazine 55 - mantendo as regras de negócios no banco de

dados: os prós e os contras. Endereço Eletrônico:<http://www.devmedia.com.br/artigo-
sql-magazine-55-mantendo-as-regras-de-negocios-no-banco-de-dados-os-pros-e-os-
contras/10350>Acesso em 27$mar.2017, 2008.
POSTGRESQL. Postgresql 9.3.5 documentation - pl/pgsql - sql procedural

language. Endereço eletrônico:<https://www.postgresql.org/docs/current/static/plpgsql-
overview.html>Acesso em 30$maio.2016, 2001.
POSTGRESQL. Chapter 37. the rule system. Endereço eletrô-

nico:<https://www.postgresql.org/docs/9.2/static/rules.html>Acesso em 30$maio.2017,
2012.
POSTGRESQL. PostgreSQL. 2015.
REZENDE, R. Conceitos fundamentais de banco de dados. Endereço

eletrônico:<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-
dados/1649> Acesso em 18$maio.2016, 2007.
SANTOS, A. Microsoft sql server development: Banco de da-

dos para desenvolvimento multicamadas. Endereço eletrô-
nico:<http://www.devmedia.com.br/articles/viewcomp.asp?comp=31787> Acesso em
07$maio.2016, 2014.
SOARES, F. Especialização em desenvolvimento de aplicações web com interfaces

ricas. Endereço eletrônico:<http://www.inf.ufg.br/ fabrizzio/web/ejb/aula04.pdf> Acesso
em 15$maio.2016, 2007.
Anexos
ANEXO A – SCRIPT DE CRIAÇÃO DO
BANCO DE DADOS
1 CREATE DATABASE SOS WITH TEMPLATE = TEMPLATE0 ENCODING = ’ UTF8 ’

LC_COLLATE = ’ PORT UGUESE _BRAZI L .1252 ’ LC_CTYPE = ’
PORT UGUES E_BRAZ IL .1252 ’;
2
3 CREATE TABLE PESSOAS (

4 ID_PESSOA SERIAL NOT NULL ,
5 NOME CHARACTER VARYING (255) NOT NULL ,
6 NOME_FANTASIA CHARACTER VARYING (255) ,
7 NOME_SOCIAL CHARACTER VARYING (255) ,
8 DT_NASCIMENTO DATE ,
9 OBSERVACAO CHARACTER VARYING (1024) ,
10 CPF_CNPJ CHARACTER (20) ,
11 RG_IE CHARACTER (20) ,
12 DT_ALTERACAO DATE NOT NULL ,
13 CONSTRAINT ID_PESSOA_PK PRIMARY KEY ( ID_PESSOA )
14 );
15
16 CREATE TABLE CLIENTES (

17 ID_CLIENTE SERIAL NOT NULL ,
18 DT_ALTERACAO DATE ,
19 ID_PESSOA INTEGER NOT NULL ,
20 CONSTRAINT ID_CLIENTE_PK PRIMARY KEY ( ID_CLIENTE ) ,
21 FOREIGN KEY ( ID_PESSOA ) REFERENCES PESSOAS ( ID_PESSOA )
22 );
23
24
25 CREATE TABLE USUARIOS (

26 ID_USUARIO SERIAL NOT NULL ,
27 SENHA CHARACTER (10) ,
30 CONSTRAINT ID_USUARIO_PK PRIMARY KEY ( ID_USUARIO ) ,
32 );
33
49
34 CREATE TABLE SITUACOES_OS (

35 ID_SITUACAO SERIAL NOT NULL ,
36 DESCRICAO CHARACTER VARYING (255) ,
37 IND_TECNICO CHARACTER (1) ,
38 IND_FINALIZA CHARACTER (1) ,
39 CONSTRAINT ID_SITUACAO_PK PRIMARY KEY ( ID_SITUACAO )
40 );
41
42 CREATE TABLE ORDENS_SERVICO (

43 ID_ORDEM_SERVICO SERIAL NOT NULL ,
44 COD_OS CHARACTER (10) ,
45 MARCA CHARACTER VARYING (255) ,
46 MODELO CHARACTER VARYING (255) ,
47 NUM_SERIE CHARACTER VARYING (100) ,
48 OPERADORA CHARACTER VARYING (255) ,
49 DEFEITO CHARACTER VARYING (1024) ,
50 LAUDO CHARACTER VARYING (1024) ,
51 INF O_COMP LEMENT AR CHARACTER VARYING (1024) ,
52 VALOR_SERVICO NUMERIC (10 ,2) ,
53 VALOR_PECAS NUMERIC (10 ,2) ,
54 DT_ENTRADA DATE ,
55 DT_SAIDA DATE ,
56 ID_USUARIO INTEGER NOT NULL ,
57 ID_CLIENTE INTEGER NOT NULL ,
58 CONSTRAINT I D _O R D EM _ S ER V I CO _ P K PRIMARY KEY ( ID_ORDEM_SERVICO )
,
59 FOREIGN KEY ( ID_USUARIO ) REFERENCES USUARIOS ( ID_USUARIO ) ,
60 FOREIGN KEY ( ID_CLIENTE ) REFERENCES CLIENTES ( ID_CLIENTE )
61 );
62
63 CREATE TABLE ENDERECOS (

64 ID_ENDERECO SERIAL NOT NULL ,
65 LOGRADOURO CHARACTER VARYING (255) NOT NULL ,
66 TELEFONE_1 CHARACTER VARYING (15) NOT NULL ,
67 TELEFONE_2 CHARACTER VARYING (10) ,
68 TELEFONE_3 CHARACTER VARYING (15) ,
69 NUMERO CHARACTER (10) ,
70 COMPLEMENTO CHARACTER VARYING (255) ,
71 BAIRRO CHARACTER VARYING (255) NOT NULL ,
72 MUNICIPIO CHARACTER VARYING (255) ,
73 CEP CHARACTER (10) ,
74 EMAIL CHARACTER VARYING (255) ,
50
75 IND_ATIVO CHARACTER (1) ,

78 CONSTRAINT ID_ENDERECO_PK PRIMARY KEY ( ID_ENDERECO ) ,
80 );
81
82
83 CREATE TABLE TECNICOS (

84 ID_TECNICO SERIAL NOT NULL ,
86 CONSTRAINT ID_TECNICO_PK PRIMARY KEY ( ID_TECNICO ) ,
87 FOREIGN KEY ( ID_USUARIO ) REFERENCES USUARIOS ( ID_USUARIO )
88 );
89
90 CREATE TABLE ALTERACOES_OS (

91 ID_ALTERACAO_OS SERIAL NOT NULL ,
93 HR_ALTERACAO TIMESTAMP WITHOUT TIME ZONE ,
95 ID_ORDEM_SERVICO INTEGER NOT NULL ,
96 ID_SITUACAO INTEGER NOT NULL ,
97 ID_TECNICO INTEGER NOT NULL ,
98 CONSTRAINT I D_A LT ER AC AO _O S_ PK PRIMARY KEY ( ID_ALTERACAO_OS ) ,
99 FOREIGN KEY ( ID_USUARIO ) REFERENCES USUARIOS ( ID_USUARIO ) ,
100 FOREIGN KEY ( ID_ORDEM_SERVICO ) REFERENCES ORDENS_SERVICO (
ID_ORDEM_SERVICO ) ,
101 FOREIGN KEY ( ID_SITUACAO ) REFERENCES SITUACOES_OS ( ID_SITUACAO
),
102 FOREIGN KEY ( ID_TECNICO ) REFERENCES TECNICOS ( ID_TECNICO )
103 );
Listing A.1 – Fonte: Própio Autor
ANEXO B – SCRIPT PARA POPULAR
O BANCO DE DADOS
1 INSERT INTO pessoas VALUES (1 , ’ Kareem Cox ’ , ’ Commodo Tincidunt

Nibh Institute ’ , ’ Curtis , Kendall K . ’ , ’ 2017 -11 -10 ’ , NULL , ’
1674020213999 ’ , ’ 1676021285099 ’ , ’ 2017 -06 -23 ’) ;
2 INSERT INTO pessoas VALUES (2 , ’ Louis Garrison ’ , ’ Nec Enim LLC ’ ,
’ Franks , Nichole G . ’ , ’ 2016 -11 -25 ’ , NULL , ’ 1611112553599 ’ , ’
1643031935599 ’ , ’ 2016 -04 -06 ’) ;
3 INSERT INTO pessoas VALUES (3 , ’ Reese Cortez ’ , ’ Imperdiet
Associates ’ , ’ Martinez , Jocelyn T . ’ , ’ 2017 -10 -25 ’ , NULL , ’
1611081763899 ’ , ’ 1664101414399 ’ , ’ 2017 -06 -18 ’) ;
4 INSERT INTO pessoas VALUES (4 , ’ Magee Talley ’ , ’ In Magna Company
’ , ’ Winters , Hamish F . ’ , ’ 2016 -11 -07 ’ , NULL , ’ 1640021006599 ’ , ’
1659040425499 ’ , ’ 2017 -06 -29 ’) ;
5 INSERT INTO pessoas VALUES (5 , ’ Odysseus Serrano ’ , ’ Neque Inc . ’ ,
’ Montoya , Joy Q . ’ , ’ 2016 -07 -19 ’ , NULL , ’ 1639101984099 ’ , ’
1639081154099 ’ , ’ 2016 -04 -11 ’) ;
6 INSERT INTO pessoas VALUES (6 , ’ Kenyon Carpenter ’ , ’ Maecenas
Ornare Corp . ’ , ’ Snow , Harriet H . ’ , ’ 2016 -10 -28 ’ , NULL , ’
1603071578099 ’ , ’ 1671082678599 ’ , ’ 2018 -03 -24 ’) ;
7 INSERT INTO pessoas VALUES (7 , ’ Gabriel Fuller ’ , ’ In Faucibus
LLP ’ , ’ Carlson , Kareem C . ’ , ’ 2017 -08 -25 ’ , NULL , ’ 1641011996399 ’
, ’ 1640061373599 ’ , ’ 2016 -12 -01 ’) ;
8 INSERT INTO pessoas VALUES (8 , ’ Orlando Nielsen ’ , ’ Arcu
Curabitur Ut Corp . ’ , ’ Marsh , Simone I . ’ , ’ 2018 -03 -18 ’ , NULL , ’
1630122131499 ’ , ’ 1644042672599 ’ , ’ 2016 -06 -03 ’) ;
9 INSERT INTO pessoas VALUES (9 , ’ Fulton Monroe ’ , ’ Diam Eu PC ’ , ’
Meyer , Lael S . ’ , ’ 2016 -08 -25 ’ , NULL , ’ 1619101276999 ’ , ’
1690020264399 ’ , ’ 2016 -06 -01 ’) ;
10 INSERT INTO pessoas VALUES (10 , ’ Walter Keith ’ , ’ Pharetra Ltd ’ ,
’ Middleton , Bevis T . ’ , ’ 2016 -11 -23 ’ , NULL , ’ 1699020763399 ’ , ’
1614111162899 ’ , ’ 2018 -03 -14 ’) ;
11 INSERT INTO pessoas VALUES (11 , ’ Malcolm Hinton ’ , ’ In Industries
’ , ’ Stafford , Norman H . ’ , ’ 2017 -04 -06 ’ , NULL , ’ 1619011893599 ’ ,
’ 1602122715799 ’ , ’ 2017 -06 -21 ’) ;
12 INSERT INTO pessoas VALUES (12 , ’ Isaiah Love ’ , ’ Vehicula Aliquet
Libero Consulting ’ , ’ Avery , Jameson K . ’ , ’ 2016 -08 -10 ’ , NULL , ’
1605041631099 ’ , ’ 1618062748499 ’ , ’ 2018 -03 -29 ’) ;
52
13 INSERT INTO pessoas VALUES (13 , ’ Dylan Serrano ’ , ’ Orci LLP ’ , ’

Gates , Iliana Q . ’ , ’ 2017 -06 -28 ’ , NULL , ’ 1631071104699 ’ , ’
1652020891199 ’ , ’ 2017 -06 -27 ’) ;
14
15 INSERT INTO situacoes \ _os VALUES (1 , ’ CONSERTADO ’ , ’S ’ , ’N ’) ;

16 INSERT INTO situacoes \ _os VALUES (2 , ’ ORAMENTO ’ , ’S ’ , ’N ’) ;
17
18 INSERT INTO situacoes \ _os VALUES (4 , ’ SEM CONSERTO ’ , ’N ’ , ’S ’) ;

19 INSERT INTO situacoes \ _os VALUES (5 , ’ RETIRADO ’ , ’N ’ , ’S ’) ;
20
21 INSERT INTO usuarios VALUES (1 , ’ 71351 ’ , ’ 2017 -04 -23 ’ , 5) ;

25
26 INSERT INTO tecnicos VALUES (1 , 3) ;

27 INSERT INTO tecnicos VALUES (2 , 1) ;
28
29 INSERT INTO clientes VALUES (1 , ’ 2016 -12 -27 ’ , 3) ;

39
40 INSERT INTO enderecos VALUES (1 , ’P . O . Box 755 , 9050 Egestas . St .

’ , ’ 20 651 -6601 ’ , NULL , NULL , ’ 74842 ’ , NULL , ’ ’ , ’ ’ , ’ 67544 ’ , ’
ipsum . Phasellus . v i t a e @ I n t e g e r m o l l i s I n t e g e r . edu ’ , ’S ’ , ’
2014 -05 -26 ’ , 1) ;
41 INSERT INTO enderecos VALUES (2 , ’P . O . Box 729 , 9550 At Av . ’ , ’ 49
871 -3993 ’ , NULL , NULL , ’ 77867 ’ , NULL , ’ ’ , ’ ’ , ’ 7800 ’ , ’ quis .
a r c u @ o d i o A l i q u a m v u l p u t a t e . com ’ , ’S ’ , ’ 2014 -09 -24 ’ , 3) ;
42 INSERT INTO enderecos VALUES (3 , ’P . O . Box 197 , 3379 Cubilia
Street ’ , ’ 77 638 -7826 ’ , NULL , NULL , ’ 59996 ’ , NULL , ’ ’ , ’ ’ , ’
2755 ’ , ’ nulla@lectussit . ca ’ , ’S ’ , ’ 2014 -09 -01 ’ , 2) ;
43 INSERT INTO enderecos VALUES (4 , ’ Ap #653 -6536 Pede . St . ’ , ’ 91
110 -9453 ’ , NULL , NULL , ’ 41807 ’ , NULL , ’ ’ , ’ ’ , ’ 90100 ’ , ’ egestas
. urn a@ r i su s D on e c ni b h . net ’ , ’S ’ , ’ 2014 -04 -05 ’ , 5) ;
53
44 INSERT INTO enderecos VALUES (5 , ’P . O . Box 876 , 255 Diam Street ’

, ’ 07 703 -2515 ’ , NULL , NULL , ’ 75498 ’ , NULL , ’ ’ , ’ ’ , ’ 3940 VQ
’ , ’ et@Sedauctor . com ’ , ’S ’ , ’ 2016 -09 -17 ’ , 4) ;
45 INSERT INTO enderecos VALUES (6 , ’ Ap #372 -5846 Orci Avenue ’ , ’ 31
693 -6038 ’ , NULL , NULL , ’ 38858 ’ , NULL , ’ ’ , ’ ’ , ’ 79343 ’ , ’
p u ru s @ m a u r i s s a p i e n c u r s u s . edu ’ , ’S ’ , ’ 2015 -07 -30 ’ , 6) ;
46 INSERT INTO enderecos VALUES (7 , ’ 316 -8246 Ut St . ’ , ’ 65 508 -5380
’ , NULL , NULL , ’ 76077 ’ , NULL , ’ ’ , ’ ’ , ’ 4794 ’ , ’ ante .
iaculis@Nunc . co . uk ’ , ’S ’ , ’ 2016 -06 -28 ’ , 7) ;
47 INSERT INTO enderecos VALUES (8 , ’ 298 -2360 Ullamcorper . Rd . ’ , ’
08 568 -3284 ’ , NULL , NULL , ’ 42944 ’ , NULL , ’ ’ , ’ ’ , ’ 5749 ’ , ’
ipsum . cursus . v e s t i b u l u m @ N u l l a e g e t . ca ’ , ’S ’ , ’ 2015 -07 -30 ’ , 8) ;
48 INSERT INTO enderecos VALUES (9 , ’ Ap #638 -2588 Arcu . Ave ’ , ’ 90
814 -2852 ’ , NULL , NULL , ’ 39938 ’ , NULL , ’ ’ , ’ ’ , ’ 982444 ’, ’
euismod . ac . f er m e n tu m @ eu i s mo d a c . ca ’ , ’S ’ , ’ 2017 -05 -25 ’ , 10) ;
49 INSERT INTO enderecos VALUES (10 , ’ 967 -1343 Molestie Rd . ’ , ’ 44
538 -4919 ’ , NULL , NULL , ’ 62526 ’ , NULL , ’ ’ , ’ ’ , ’ 1552 OY ’, ’
h y m e n a e o s @ v e s t i b u l u m m a s s a r u t r u m . edu ’ , ’S ’ , ’ 2016 -01 -29 ’ , 9) ;
50
51 INSERT INTO ordens_servico VALUES (1 , ’ 100 ’ , ’ Lorem ipsum dolor

sit amet ’ , ’ modelo1 ’ , ’ 780259725 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum
dolor sit ’ , 8.29 , 7.27 , ’ 2016 -10 -27 ’ , ’ 2017 -01 -27 ’ , 1 , 4) ;
52 INSERT INTO ordens_servico VALUES (2 , ’ 101 ’ , ’ Lorem ipsum dolor ’
, ’ model3 ’ , ’ 888616293 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum dolor sit
amet ’ , 3.90 , 1.84 , ’ 2016 -09 -16 ’ , ’ 2017 -07 -03 ’ , 2 , 4) ;
sit amet ’ , ’ mode ’ , ’ 596942911 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum dolor
’ , 8.58 , 9.06 , ’ 2016 -12 -29 ’ , ’ 2016 -06 -25 ’ , 3 , 7) ;
, ’ mod ’ , ’ 875572202 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum dolor sit amet ,
consectetuer adipiscing elit . ’ , 0.31 , 5.55 , ’ 2017 -12 -04 ’ , ’
2017 -06 -11 ’ , 4 , 1) ;
55 INSERT INTO ordens_servico VALUES (5 , ’ 104 ’ , ’ Lorem ’ , ’ mol ’ , ’
688682292 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum dolor ’ , 4.04 , 4.20 , ’
2017 -08 -24 ’ , ’ 2018 -06 -17 ’ , 3 , 2) ;
sit amet ’ , ’ consectetuer ’ , ’ 804682225 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem
ipsum dolor sit am ’ , 2.17 , 8.87 , ’ 2018 -04 -04 ’ , ’ 2017 -10 -05 ’ , 4 ,
5) ;
sit amet ’ , ’ consectetuer adipiscing elit . Curabitur sed ’ , ’
696637391 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lore ’ , 0.26 , 4.92 , ’ 2017 -10 -14 ’ , ’
54
2017 -06 -25 ’ , 3 , 8) ;

58 INSERT INTO ordens_servico VALUES (8 , ’ 107 ’ , ’ Lorem ipsum ’ , ’ ’ ,
’ 588619675 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum ’ , 7.76 , 5.94 , ’
2016 -10 -08 ’ , ’ 2018 -02 -27 ’ , 3 , 7) ;
, ’ mod ’ , ’ 679180859 ’ , ’ VIVO ’ , ’ ’ , ’ ’ , ’ Lorem ipsum dolor sit amet
, consectetuer adipiscing elit . ’ , 4.49 , 3.93 , ’ 2018 -05 -05 ’ , ’
2018 -01 -20 ’ , 3 , 5) ;
60
61
62 INSERT INTO alteracoes_os VALUES (1 , ’ 2018 -05 -19 ’ , ’ 2017 -06 -24
02:23:23.178067 ’ , 2 , 1 , 5 , 1) ;
02:23:23.178067 ’ , 1 , 4 , 1 , 2) ;
02:23:23.178067 ’ , 2 , 6 , 4 , 1) ;
02:23:23.178067 ’ , 3 , 3 , 1 , 2) ;
02:23:23.178067 ’ , 4 , 5 , 5 , 1) ;
02:23:23.178067 ’ , 4 , 3 , 4 , 1) ;
02:23:23.178067 ’ , 2 , 3 , 3 , 2) ;
02:23:23.178067 ’ , 4 , 8 , 5 , 1) ;
Listing B.1 – Fonte: Própio Autor

Atila Cordeiro Biolchi

Enviado por

Direitos autorais:

Formatos disponíveis

Atila Cordeiro Biolchi

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Atila Cordeiro Biolchi

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE REGIONAL DO NOROESTE DO

ESTADO DO RIO GRANDE DO SUL

ÁTILA CORDEIRO BIOLCHI

AVALIAÇÃO DA IMPLEMENTAÇÃO DE REGRAS DE

Trabalho apresentado ao curso de Ciência

Orientador: Prof. Me. Leonardo Minelli

Também agradeço a minha mãe, Suzete, que me incentivou a nunca deixar

Agradeço ainda ao professor Leonardo Minelli, que me orientou durante o

Palavras-chaves: Banco de Dados, Regra de Negocio, SGBD, Multicamadas, PL/SQL.

Keywords: Database, Business Rules, DBMS, Multi-layer, PL/SQL.

Figura 1 – Modelo de três camadas . . . . . . . . . . . . . . . . . . . . . . . . . 15

Tabela 1 – Resultado da Execução . . . . . . . . . . . . . . . . . . . . . . . . . 30

API Application Programming Interface

IDE Integrated Development Environment

PL/SQL Procedural Language

PL/pgSQL Procedural Language PostgreSQL

RAD Rapid Application Development

SGBD Sistema de Gerenciamento de Banco de dados

SQL Structured Query Language

3 MODELAGEM E ESTUDO DE CASO . . . . . . . . . . . . . . . . . . 26

4 IMPLEMENTAÇÃO DO ESTUDO DE CASO . . . . . . . . . . . . . . 35

ANEXO A – SCRIPT DE CRIAÇÃO DO BANCO DE DADOS . . . . 48

As regras de negócio podem ser definidas como um conjunto de práticas de

De acordo com (HAY; HEALY, 1997) regras de negócio podem aparecer de

No modelo de sistema de três ou mais camadas, conhecido por n-camada, a

Estes sistemas em suas versões mais recentes, permitem a implementação

De acordo (POSTGRESQL, 2015), um banco de dados de classe corporativa

Ainda segundo (POSTGRESQL, 2015), o PostgreSQL suporta conjuntos de

pontos é altamente escalável para grande quantidade. Existem sistemas ativos do

Neste sentido o presente trabalho abordará técnicas de implementação de

Dada a complexidade citada na introdução do presente trabalho, faz se neces-

2.1 Arquitetura multicamadas

Sabendo da complexidade dos sistemas, o desenvolvimento e a manutenção

A arquitetura multicamadas estabelece que, para que um projeto seja efi-

A multicamada implementa uma lógica de objetos distribuídos vinculados

A ideia básica do modelo de 3 camadas, é "retirar"as Regras do Negócio

Na arquitetura de sistemas a abstração é muito importante, pois permite que o

Esta abstração entre as camadas permite a melhor organização das regras de

Figura 1 – Modelo de três camadas

Fonte: Battisti (2003)

Embora a implementação do modelo de 3 camadas seja a mais utilizada, este

Algumas literaturas tratam o assunto multicamadas como sendo uma

Nestes modelos, uma camada acessa apenas os componentes públicos da

De acordo com (SANTOS, 2014), o modelo de desenvolvimento multicama-

Figura 2 – Modelo n camadas

Fonte: Soares (2007)

2.1.1 Camada de Apresentação

A camada de apresentação é a interface do software, é através desta camada

Alterações na Interface do programa, geram a necessidade de atua-

No caso de aplicações web:

A interface pode ser composta de páginas HTML, ASP, ou qualquer

Ao contrário de um aplicação de linha de comando, como o terminal do Linux ou

Em seu estudos, (SANTOS, 2014), constatou que a camada de apresentação

2.1.2 Camada de Regras de Negócio

As regras de negócio são geralmente um conjunto de declarações ou condições

Estas regras fornecem orientações relacionadas com as ações ou atividades

Qualquer empresa, independente de porte, ramo de atividade, número

Uma regra de negócios se refere à forma como uma organização ou empresa

A camada de regras de negócio de um sistema tem por objetivo implementar