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
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.
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)
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.
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.
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
LISTA DE TABELAS
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 . . . . 481 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
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 à apliunifi-caçã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).
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).
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.
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
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..
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,
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).
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 C R E A T E [ OR R E P L A C E ] 2 [ T E M P | T E M P O R A R Y ] 3 [ R E C U R S I V E ] 4 V I E W n a m e [ ( c o l u m n _ n a m e [ , . . . ] ) ] 5 [ W I T H ( v i e w _ o p t i o n _ n a m e [= v i e w _ o p t i o n _ v a l u e ] [ , ... ] ) ] AS q u e r y
Figura 6 – Exemplo de uma View composta 1 C R E A T E OR R E P L A C E V I E W v _ g e t _ d a d o s _ o s as 2 s e l e c t p . nome , 3 p . c p f _ c n p j , 4 os . i d _ o r d e m _ s e r v i c o , 5 s . d e s c r i c a o , 6 T O _ C H A R ( a . d t _ a l t e r a c a o , ’ DD / MM / Y Y Y Y ’) 7 f r o m p e s s o a s p 8 j o i n c l i e n t e s c on 9 ( c . i d _ p e s s o a = p . i d _ p e s s o a ) 10 j o i n o r d e n s _ s e r v i c o os on 11 ( os . i d _ c l i e n t e = c . i d _ c l i e n t e ) 12 j o i n a l t e r a c o e s _ o s a on 13 ( a . i d _ o r d e m _ s e r v i c o = os . i d _ o r d e m _ s e r v i c o ) 14 j o i n s i t u a c o e s _ o s s on 15 ( s . i d _ s i t u a c a o = a . i d _ s i t u a c a o ) 16 o r d e r by cod_os , 17 s . i d _ s i t u a c a o d e s c
Fonte: Próprio Autor
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 C R E A T E [ OR R E P L A C E ] F U N C T I O N 2 n a m e ( [ [ a r g m o d e ] [ a r g n a m e ] a r g t y p e [ { D E F A U L T | = } d e f a u l t _ e x p r ] [ , . . . ] ] ) 3 [ R E T U R N S r e t t y p e 4 | R E T U R N S T A B L E ( c o l u m n _ n a m e c o l u m n _ t y p e [ , . . . ] ) ] 5 { L A N G U A G E l a n g _ n a m e 6 | W I N D O W 7 | I M M U T A B L E | S T A B L E | V O L A T I L E 8 | C A L L E D ON N U L L I N P U T | R E T U R N S N U L L ON N U L L I N P U T | S T R I C T 9 | [ E X T E R N A L ] S E C U R I T Y I N V O K E R | [ E X T E R N A L ] S E C U R I T Y D E F I N E R 10 | C O S T e x e c u t i o n _ c o s t 11 | R O W S r e s u l t _ r o w s 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 v a l u e | = v a l u e | F R O M C U R R E N T } 13 | AS ’ d e f i n i t i o n ’ 14 | AS ’ o b j _ f i l e ’, ’ l i n k _ s y m b o l ’ 15 } ... 16 [ W I T H ( a t t r i b u t e [ , . . . ] ) ]
Fonte: Próprio Autor
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 é
Figura 8 – Função Armazenada do tipo tabela 1 C R E A T E OR R E P L A C E F U N C T I O N g e t _ d a d o s _ o s () 2 R E T U R N S T A B L E( 3 n o m e v ar c ha r, 4 c p f _ c n p f char, 5 os i nt e ge r, 6 d e s c r i c a o v ar c ha r, 7 d a t a _ a l t e r a c a o c h a r) 8 AS 9 $$ 10 s e l e c t p . nome , 11 p . c p f _ c n p j , 12 os . i d _ o r d e m _ s e r v i c o , 13 s . d e s c r i c a o , 14 T O _ C H A R ( a . d t _ a l t e r a c a o , ’ DD / MM / Y Y Y Y ’) 15 f r o m p e s s o a s p 16 j o i n c l i e n t e s c on 17 ( c . i d _ p e s s o a = p . i d _ p e s s o a ) 18 j o i n o r d e n s _ s e r v i c o os on 19 ( os . i d _ c l i e n t e = c . i d _ c l i e n t e ) 20 j o i n a l t e r a c o e s _ o s a on 21 ( a . i d _ o r d e m _ s e r v i c o = os . i d _ o r d e m _ s e r v i c o ) 22 j o i n s i t u a c o e s _ o s s on 23 ( s . i d _ s i t u a c a o = a . i d _ s i t u a c a o ) 24 o r d e r by cod_os , 25 s . i d _ s i t u a c a o d e s c 26 $$ 27 L A N G U A G E ’ sql ’ V O L A T I L E ;
Fonte: Próprio Autor
Figura 9 – Execução da função
1 S E L E C T *
2 F R O M g e t _ d a d o s _ o s () ;
Fonte: Próprio Autor
Figura 10 – Execução da função
1 S E L E C T *
2 F R O M g e t _ d a d o s _ o s ()
3 w h e r e os = 2 0 1 ;
Fonte: Próprio Autor
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 C R E A T E OR R E P L A C E F U N C T I O N g e t _ d a d o s _ p o r _ o s ( I D O S i n t e g e r) 2 R E T U R N S T A B L E( 3 n o m e v ar c ha r, 4 c p f _ c n p f char, 5 os i nt e ge r, 6 d e s c r i c a o v ar c ha r, 7 d a t a _ a l t e r a c a o c h a r) 8 AS 9 $$ 10 s e l e c t p . nome , 11 p . c p f _ c n p j , 12 os . i d _ o r d e m _ s e r v i c o , 13 s . d e s c r i c a o , 14 T O _ C H A R ( a . d t _ a l t e r a c a o , ’ DD / MM / Y Y Y Y ’) 15 f r o m p e s s o a s p 16 j o i n c l i e n t e s c on 17 ( c . i d _ p e s s o a = p . i d _ p e s s o a ) 18 j o i n o r d e n s _ s e r v i c o os on 19 ( os . i d _ c l i e n t e = c . i d _ c l i e n t e ) 20 j o i n a l t e r a c o e s _ o s a on 21 ( a . i d _ o r d e m _ s e r v i c o = os . i d _ o r d e m _ s e r v i c o ) 22 j o i n s i t u a c o e s _ o s s on 23 ( s . i d _ s i t u a c a o = a . i d _ s i t u a c a o ) 24 w h e r e os . i d _ o r d e m _ s e r v i c o = i d o s 25 o r d e r by cod_os , 26 s . i d _ s i t u a c a o d e s c 27 $$ 28 L A N G U A G E ’ sql ’ V O L A T I L E ;
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 C R E A T E OR R E P L A C E F U N C T I O N i n s e r e _ a l t e r a c o e s _ o s 2 ( d t _ a l t e r a c a o date, 3 h r _ a l t e r a c a o t i m e s t a m p , 4 i d _ u s u a r i o i nt e ge r, 5 i d _ o r d e m _ s e r v i c o i nt e ge r, 6 i d _ s i t u a c a o i nt e ge r, 7 i d _ t e c n i c o i n t e g e r) 8 r e t u r n s v o i d as 9 $$ 10 b e g i n 11 I N S E R T I N T O a l t e r a c o e s _ o s 12 v a l u e s ( Nextval , 13 d t _ a l t e r a c a o , 14 h r _ a l t e r a c a o , 15 i d _ u s u a r i o , 16 i d _ o r d e m _ s e r v i c o , 17 i d _ s i t u a c a o , 18 i d _ t e c n i c o ) ; 19 end; 20 $$ L A N G U A G E ’ p l p g s q l ’;
Fonte: Próprio Autor
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 C R E A T E T R I G G E R n o m e { B E F O R E | A F T E R }
2 { I N S E R T | U P D A T E | D E L E T E [ OR ... ] }
3 ON t a b e l a [ FOR [ E A C H ] { ROW | S T A T E M E N T } ]
4 E X E C U T E P R O C E D U R E n o m e _ f u n c i o n ( a r g u m e n t o s )
Fonte: Próprio Autor
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.
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
Fonte: Próprio Autor
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)
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
1 I N S E R T I N T O a l t e r a c o e s _ o s 2 V A L U E S ( i d _ a l t e r a c a o _ o s , 3 d t _ a l t e r a c a o , 4 h r _ a l t e r a c a o , 5 i d _ u s u a r i o , 6 i d _ o r d e m _ s e r v i c o , 7 i d _ s i t u a c a o , 8 i d _ t e c n i c o ) ;
Fonte: Próprio Autor
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 C R E A T E OR R E P L A C E F U N C T I O N
2 i n s e r e _ a l t e r a c o e s _ o s ( i d _ u s u a r i o i nt e ge r,
3 i d _ o r d e m _ s e r v i c o i nt e ge r,
4 i d _ s i t u a c a o i n t e g e r) ;
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 C R E A T E OR R E P L A C E F U N C T I O N i n s e r e _ a l t e r a c o e s _ o s ( i d u s u a r i o i nt e ge r, 2 i d o r d e s e r v i c o i nt e ge r, 3 i d s i t u a c a o i n t e g e r) 4 R E T U R N S v o i d AS 5 $ B O D Y $ 6 b e g i n 7 I N S E R T I N T O a l t e r a c o e s _ o s 8 v a l u e s ( Nextval , 9 c u r r e n t _ d a t e, 10 c u r r e n t _ t i m e, 11 i d u s u a r i o , 12 i d o r d e s e r v i c o , 13 i d s i t u a c a o , 14 (s e l e c t i d _ u s u a r i o 15 f r o m t e c n i c o s 16 w h e r e i d _ u s u a r i o = i d u s u a r i o ) 17 ) ; 18 end; 19 $ B O D Y $ 20 L A N G U A G E p l p g s q l V O L A T I L E ;
Fonte: Próprio Autor
É 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:
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 s e l e c t a . d t _ a l t e r a c a o , 2 s . d e s c r i c a o , 3 p . n o m e 4 f r o m a l t e r a c o e s _ o s a , 5 s i t u a c o e s _ o s s , 6 u s u a r i o s u , 7 p e s s o a s p 8 w h e r e a . i d _ s i t u a c a o = s . i d _ s i t u a c a o and 9 a . i d _ u s u a r i o = u . i d _ u s u a r i o and 10 u . i d _ p e s s o a = p . i d _ p e s s o a and 11 a . i d _ o r d e m _ s e r v i c o = 123 12 o r d e r by d t _ a l t e r a c a o d e s c;
Fonte: Próprio Autor
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 comandoCREATE FUNCTION, nestas situações, é necessário
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 D R O P F U N C T I O N i n s e r e _ a l t e r a c o e s _ o s ( i d u s u a r i o i nt e ge r, i d o r d e s e r v i c o i nt e ge r, i d s i t u a c a o i n t e g e r) ; 2 3 C R E A T E F U N C T I O N i n s e r e _ a l t e r a c o e s _ o s ( i d u s u a r i o i nt e ge r, 4 i d o r d e s e r v i c o i nt e ge r, 5 i d s i t u a c a o i n t e g e r) 6 R E T U R N S T A B L E( d t _ a l t e r a c a o date, d e s c r i c a o c h a r a c t e r, n o m e c h a r a c t e r) AS 7 $ B O D Y $ 8 b e g i n 9 I N S E R T I N T O a l t e r a c o e s _ o s v a l u e s ( Nextval , 10 c u r r e n t _ d a t e, 11 c u r r e n t _ t i m e, 12 i d u s u a r i o , 13 i d o r d e s e r v i c o , 14 i d s i t u a c a o , 15 (s e l e c t i d _ u s u a r i o 16 f r o m t e c n i c o s 17 w h e r e i d _ u s u a r i o = i d u s u a r i o ) ) ; 18 s e l e c t a . d t _ a l t e r a c a o , 19 s . d e s c r i c a o , 20 p . n o m e 21 f r o m a l t e r a c o e s _ o s a , 22 s i t u a c o e s _ o s s , 23 u s u a r i o s u , 24 p e s s o a s p 25 w h e r e a . i d _ s i t u a c a o = s . i d _ s i t u a c a o and 26 a . i d _ u s u a r i o = u . i d _ u s u a r i o and 27 u . i d _ p e s s o a = p . i d _ p e s s o a and 28 a . i d _ o r d e m _ s e r v i c o = i d o r d e s e r v i c o 29 o r d e r by d t _ a l t e r a c a o d e s c; 30 end; 31 $ B O D Y $ 32 L A N G U A G E p l p g s q l V O L A T I L E ;
Fonte: Próprio Autor
É 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.
42
Figura 22 – Estrutura do Catalogo
Fonte: Próprio Autor
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.
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.
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.
