mal; TEXT-ALIGN: left; mso-pagination: widow-orphan; mso-outline-level: body-text" align=left>Oralce
Construindo Aplicações no Oracle
Stored Procedures - Procedures, Functions e Packages – Parte II
Nesta segunda parte do artigo sobre construção de aplicações no Oracle, utilizaremos as funcionalidades vistas no primeiro artigo para construir os famosos pacotes, ou packages como são conhecidos.
Em resumo, packages nada mais são que um mecanismo para agrupar logicamente pequenos programas que possuem uma interdependência.
Esta interdependência não se trata de, por exemplo, uma procedure que depende do resultado da execução de outra. Por outro lado, caso tenhamos uma procedure usada na admissão de um funcionário, essa procedure estará agrupada no mesmo pacote que a procedure de demissão de funcionário.
Apenas é importante salientar que isto não é uma regra, apenas uma boa prática.
O ambiente
O ambiente é o mesmo utilizado na primeira parte do artigo, ou seja, um Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 com o velho e bom esquema de demonstração SCOTT.
Por que usar Packages?
Uma package é um poderoso e importante elemento da linguagem PL/SQL que pode ser utilizado em qualquer projeto de desenvolvimento de aplicação. Mas afinal, o que torna uma package não importante e poderosa?
Posso citar aqui quatro considerações básicas:
1. Facilidade de desenvolvimento e manutenção: através da redução substancial da quantidade de código, utilização das mesmas constantes ou “números mágicos” utilizados em funções similares ou relacionadas e principalmente pela redução dos pontos de falha da aplicação;
2. Melhoria na performance global da aplicação: informações de packages persistentes pode garantir uma melhora significativa no tempo de resposta de consultas através do “cache” de dados estatísticos evitando repetidas consultas à mesma informação. Outro fator que garante esta melhoria é que o gerenciamento de memória do Oracle otimiza o acesso a códigos contidos em packages;
3. Habilidade para suportar “fraquezas”de aplicações ou “packages oracle”: é extremamente simples construir packages utilizando funcionalidades existentes, como nos pacotes oferecidos pelo db oracle. Considere, por exemplo, pacotes oracle como o UTL_FILE ou DBMS_OUTPUT, que foram mal ou parcialmente implementados. Conhecemos muitas falhas nestes pacotes. Ao invés de simplesmente aceitarmos estas “fraquezas”, podemos construir o nosso próprio pacote, corrigindo muitos dos possíveis problemas;
4. Minimização da necessidade de recompilação de códigos: qualquer programa externo a uma package (uma procedure ou function que não estejam na package) podem “chamar” programas listados na package. Caso você altere e recompile a package, o programa externo não é invalidado, evitando a necessidade de recompilação do código.
Antes de iniciarmos o embasamento conceitual e a “mão na massa”, vou lhes dar uma dica que pode facilitar muito sua vida no futuro da aplicação. Veja a Dica 1.
|
Dica 1. Boa prática na construção de procedures e functions |
|
Uma idéia muito valiosa é a construção de sua aplicação Você pode me perguntar: “Mas estamos iniciando nossa aplicação e teremos apenas uma procedure, mesmo assim coloco-a em uma package?”. E minha resposta é: Sim, com certeza. E o motivo é bem simples. Neste momento, sua aplicação requer apenas uma procedure, ou apenas uma function, mas a evolução da aplicação pode tornar necessária a utilização de mais uma ou várias procedures e functions. Muito provavelmente chegará um momento em que você pensará: “Opa, o sistema está crescendo. Está começando a ficar complicado gerenciar todos estes códigos. É hora de agrupar em packages!”, e neste momento, você descobrirá que terá que rever todos os códigos que “chamam” suas procedures e functions, pois terá que acrescentar nome da package como prefixo de cada “chamada”. Que tal iniciar o projeto já utilizando packages e evitar que fique encrencado no futuro? |
Conceitos importantes sobre Packages
Antes de mostrar a sintaxe e utilização das packages, alguns conceitos precisam ser mostrados e é exatamente isso que veremos nesta seção.
Especificação da Package
A especificação da package contém a definição de todos os elementos disponíveis “publicamente”, que podem ser referenciados “de fora” da package, ou seja, a especificação da package é como uma grande seção de declarações e não contém nenhum bloco PL/SQL ou código executável.
Quando bem construída, a especificação da package fornece todas as informações necessárias para que o desenvolvedor possa utilizar esta package.
Corpo da Package (Package Body)
O corpo da package contém todo o código necessário para implementar os elementos definidos na especificação da package. O corpo da package pode conter também elementos “privados”, que não aparecem na especificação e não poderão ser referenciados “de fora” da package. Ele contém a declaração das variáveis e a definição de todos os módulos da package.
O corpo da package pode conter também uma seção de execução, que é chamada de seção de inicialização (initialization section), pois é executada apenas uma vez para iniciar a package.
Público e Privado
Basicamente, todo código público está definido na especificação da package e está disponível (ou acessível) para qualquer esquema que tenha permissão de execução (EXECUTE) para esta package.
No lado oposto a isso, todo código privado é definido e “visível” apenas internamente à package, ou seja, nenhum programa externo ou esquema poderá “ver” ou utilizar um código privado.
Para facilitar o entendimento, a Figura 1 mostra o esquema criado por Grady Booch para ilustrar este funcionamento. O diagrama da Figura 1 é conhecido como Diagrama de Booch.
Figura 1. Diagrama de Booch – entendendo o conceito de privacidade.
Seção de Inicialização
Inicialização não é um conceito novo para os programadores. Contudo, em se tratando de packages, possui um significado específico. Ao invés de inicializar o valor de uma única e simples variável, você pode inicializar toda a package, independente da complexidade do código. E o mais interessante é que o Oracle se responsabiliza em garantir que o pacote será inicializado apenas uma vez para cada sessão do banco de dados.
...
