TCCP_2015_Jamil Guimarães Siman

Prévia do material em texto

UNIVERSIDADE FEDERAL DE MATO GROSSO 
INSTITUTO DE COMPUTAÇÃO 
COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM BANCO DE DADOS 
 
 
 
 
REPOSITÓRIO DE BACKUP E VERSIONAMENTO DE 
OBJETOS METADADOS ORACLE 
 
 
 
 
 
 
JAMILL GUIMARÃES SIMAN 
 
 
 
 
 
 
 
 
 
CUIABÁ – MT 
2015 
UF MT 
 
 
 
 
 
UNIVERSIDADE FEDERAL DE MATO GROSSO 
INSTITUTO DE COMPUTAÇÃO 
COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM BANCO DE DADOS 
 
 
 
REPOSITÓRIO DE BACKUP E VERSIONAMENTO DE 
OBJETOS METADADOS ORACLE 
 
 
JAMILL GUIMÃRAES SIMAN 
 
 
Orientador: Prof. Dra. Andreia Gentil Bonfante 
 
 
Monografia apresentada ao Curso de 
Especialização em Banco de Dados, do 
Instituto de Computação da Universidade 
Federal de Mato Grosso, como requisito para a 
conclusão do Curso de Especialização Lato 
Sensu em Banco de Dados. 
 
 
 
CUIABÁ – MT 
2015 
UF MT 
 
 
 
 
 
UNIVERSIDADE FEDERAL DE MATO GROSSO 
INSTITUTO DE COMPUTAÇÃO 
COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM BANCO DE DADOS 
 
Certificado de Aprovação 
 
Monografia da Especialização em Banco de Dados, sob o título Repositório de Backup 
e Versionamento de Objetos Metadados Oracle, aprovada em 07/07/2015, pela banca 
examinadora constituída pelos professores: 
 
 
 
Profª Drª Andreia Gentil Bonfante 
Orientadora 
 
 
 
Prof. Dr. Josiel Maimone de Figueiredo 
Universidade Federal de Mato Grosso 
 
 
 
Prof. Dr. Allan Gonçalves de Oliveira 
Universidade Federal de Mato Grosso 
 
 
 
 
CUIABÁ – MT 
2015 
UF MT 
ii 
 
 
 
SUMÁRIO 
_____________________________________ 
 
INTRODUÇÃO .................................................................................................................................... 9 
1.1 OBJETIVOS DO TRABALHO .......................................................................................................... 12 
1.2 OBJETIVOS ESPECÍFICOS ............................................................................................................. 13 
1.3 JUSTIFICATIVA ............................................................................................................................ 13 
1.4 METODOLOGIA ........................................................................................................................... 14 
1.5 ESTRUTURA DO TRABALHO ........................................................................................................ 15 
FUNDAMENTAÇÃO TEÓRICA..................................................................................................... 16 
2.1 BANCO DE DADOS ...................................................................................................................... 16 
2.2 MODELOS DE DADOS .................................................................................................................. 18 
2.3 LINGUAGEM SQL ....................................................................................................................... 19 
2.4 OBJETOS DE BANCO DE DADOS ................................................................................................... 21 
2.5 SCHEMA DE BANCO .................................................................................................................... 23 
2.6 ENTENDENDO UM REPOSITÓRIO DE METADADOS ....................................................................... 24 
2.7 CONCEITOS DE BACKUP E RECUPERAÇÃO DE DADOS ORACLE .................................................... 25 
2.8 ORACLE PL/SQL ........................................................................................................................ 27 
2.9 DELPHI ....................................................................................................................................... 27 
DESENVOLVIMENTO DO REPOSITÓRIO ................................................................................ 29 
3.1 DESCRIÇÃO DO AMBIENTE ......................................................................................................... 29 
3.1.1 Estrutura Física ................................................................................................................. 29 
3.1.2 Estrutura logica ................................................................................................................. 29 
3.2 VISÃO GERAL DO REPOSITÓRIO ................................................................................................. 30 
3.2.1 Objetos Metadados ............................................................................................................ 30 
3.2.2 Dicionário de Dados .......................................................................................................... 30 
3.2.3 Agendamento de Tarefa ..................................................................................................... 30 
3.2.4 Interface Gráfica ............................................................................................................... 31 
3.3 PASSOS PARA CRIAÇÃO DO REPOSITÓRIO ................................................................................... 31 
3.4 REQUISITOS DO REPOSITÓRIO ..................................................................................................... 32 
3.5 ESPECIFICAÇÃO .......................................................................................................................... 33 
3.5.1 Diagrama de Caso de Uso ................................................................................................. 33 
3.5.2 Diagrama de Atividades .................................................................................................... 35 
3.5.3 Modelo de Dados Relacional ............................................................................................. 36 
3.5.4 Dicionário de Dados do Repositório ................................................................................. 38 
3.6 IMPLEMENTAÇÃO ....................................................................................................................... 41 
3.6.1 Técnicas e ferramentas utilizadas ...................................................................................... 41 
3.6.2 Arquitetura ......................................................................................................................... 41 
CONSIDERAÇÕES FINAIS ............................................................................................................ 48 
4.1 TRABALHOS FUTUROS ................................................................................................................ 49 
4.2 RESULTADOS E DISCUSSÕES ....................................................................................................... 49 
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................. 51 
APÊNCICE A – CÓDIGO FONTE DO REPOSITÓRIO .............................................................. 53 
 
 
iii 
 
 
 
LISTA DE FIGURAS 
______________________________________ 
Figura 1: Programação incluída na aplicação e no SGBD. .......................................... 10 
Figura 2: Componentes de um Sistema de Banco de dados. ........................................ 17 
Figura 3: Schemas em um banco de dados. .................................................................. 23 
Figura 4: Passos para construção do Repositório. ........................................................ 32 
Figura 5: Diagrama de Caso de Uso do DBA. ............................................................. 33 
Figura 6: Diagrama de Caso de Uso do Desenvolvedor............................................... 34 
Figura 7: Diagrama de Atividades. ............................................................................... 35 
Figura 8: Modelo de dados Relacional das Entidades. ................................................. 37 
Figura 9: Criando usuário no banco pela ferramenta PL/SQL..................................... 42 
Figura 10: Conectando no banco de dados pela interface gráfica. ............................... 42 
Figura 11: Criando Repositório no primeiro acesso. .................................................... 43 
Figura 12: Confirmação de criação do Repositório. ..................................................... 43 
Figura 13: Interface gráfica. ......................................................................................... 44 
Figura 14: Acessando menu configuração. .................................................................. 45 
Figura 15: Configurando backup do Repositório. ........................................................ 45 
Figura 16: Configurando agendamento de backup do Repositório. ............................. 46 
Figura 17: Listando objetos metadados no Repositório. .............................................. 46 
 
 
iv 
 
 
 
LISTA DE TABELAS 
______________________________________ 
Tabela 1: Comandos DDL. ........................................................................................... 20 
Tabela 2: Comandos DML. .......................................................................................... 20 
Tabela 3: Comandos DCL. ........................................................................................... 21 
Tabela 4: Diferentes tipos de Flashback por versões do Oracle. .................................. 26 
Tabela 5: Dicionário de Dados da Entidade usuarios_repo. ........................................ 38 
Tabela 6: Dicionário de Dados da Entidade objeto_repo. ............................................ 38 
Tabela 7: Dicionário de Dados da Entidade configura_job_repo. ............................... 39 
Tabela 8: Dicionário de Dados da Entidade repository_metadata. .............................. 39 
Tabela 9: Dicionário de Dados da Procedure prc_repositorio_metadados.................. 40 
Tabela 10: Dicionário de Dados da job job_repo. ........................................................ 40 
Tabela 11: Código Fonte do Repositório...................................................................... 53 
 
 
 
v 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
______________________________________ 
ANSI American National Standard Institute. 
BD Banco de Dados 
DB Data Base. 
DBA Data Base Administrator. 
DCL Data Control Language 
DDL Data Definition Language. 
DML Data Manipulation Language 
IDE Integrated Development Environment. 
RAD Rapid Application Development. 
RDBMS Relational Database Management System. 
RF Requisito Funcional. 
RNF Requisito Não Funcional 
RMAN Recovery Manager. 
SGBD Sistema Gerenciador de Banco de Dados. 
SQL Strutured Query Language. 
PL/SQL Procedural Language/Strutured Query Language. 
vi 
 
 
 
AGRADECIMENTOS 
______________________________________ 
A Deus por ter me dado saúde e força para superar as dificuldades. 
A esta universidade, seu corpo docente, direção e administração que 
oportunizaram a janela que hoje vislumbro um horizonte superior, eivado pela 
acendrada confiança no mérito é ética aqui presente. 
Ao minha orientadora Andreia, pelo suporte no pouco tempo que lhe coube, pelas 
suas correções e incentivos. 
A minha família, pelo amor, incentivo e apoio incondicional. 
E a todos que direta ou indiretamente fizeram parte da minha formação, o meu 
muito Obrigado. 
 
vii 
 
 
 
RESUMO 
______________________________________ 
Em desenvolvimento de sistemas é comum programarmos diversos tipos de 
objetos metadados. No banco de dados Oracle alguns desses objetos são conhecidos 
como: tabelas (tables), visões (views), índices (indexes), gatilhos (triggers), restrições 
(constraints) como chaves primárias (primary keys) e chaves estrangeiras (foreign keys), 
procedimentos armazenados (storage procedure), funções (functions), entre outros. À 
medida que esses objetos são criados no banco, há sempre uma necessidade de realizar 
o backup desses objetos metadados para posteriormente recupera-los em caso de uma 
necessidade. Utilizando algumas ferramentas que a Oracle disponibiliza para realizar 
esse processo de backup e recuperação, foram identificados alguns problemas que 
geralmente o desenvolvedor vem enfrentando, e um deles consiste em não ter o 
conhecimento necessário para manuseio dessas ferramentas ou não possuir o acesso 
necessário. Com base nessa situação a solução encontrada foi a criação de um 
repositório dentro do banco Oracle, capaz do próprio desenvolvedor escolher quais 
objetos deseja fazer backup e recuperação, sem que haja a necessidade de um 
administrador de banco de dados fazer esse trabalho, porque o repositório vai armazenar 
os scripts DDL (Data Definition Language) e o código procedimental completo de cada 
objeto criado, e assim, sempre que houver uma atualização na sua definição, ele irá 
contemplar o versionamento pela data de modificação dos objetos desde a versão atual 
até versões anteriores. 
Palavra-Chave: Repositório. Objetos Metadados. Oracle. 
 
 
viii 
 
 
 
ABSTRACT 
______________________________________ 
Developing systems and common to program several types of Objects metadata. 
In Oracle Database Some these objects are known as: tables, views, indexes, triggers, 
primary keys) and foreign keys, stored procedures, functions, other between. As 
processes objects are created in the bank, there is always a need to perform support 
these objects paragraph metadata later retrieves them in case of a need. Using some 
tools que Oracle Perform This paragraph provides process security and Recovery copy 
Were Some Problems identified que usually comes Developer facing, and these 
problems are a: do not have the required knowledge paragraph handling of these tools or 
do not have the required access . Based on this situation studied a solution was create a 
Repository Within the Oracle database, able to choose Developer what objects want to 
do backup and recovery without que Let there be a need to hum database administrator 
Make This Work, because the repository will store the DDL scripts OS (Data Definition 
Language) and procedural complete code each object created, and whenever there is an 
update in its definition, IT contemplating versioning for the modification of data objects 
from the Current Version To Previous versions. 
Keyword: Repository. Metadata Objects. Oracle.
 
Página 9 
 
CAPÍTULO 1 
 INTRODUÇÃO 
______________________________________ 
Em desenvolvimento de softwares é muito comum o desenvolvedor programar 
novas versões de softwares e quando essas versões são enviadas para o ramo de 
produção consequentemente podem possuir erros ou resultados inesperados. Diante 
destas situações, é preciso corrigir os problemas o mais rápido possível e a forma mais 
rápida normalmente é voltar à versão anterior do software (PRADO, 2012). 
Um dos mecanismos essenciais na implantação dos sistemas são os objetos 
metadados do banco de dados. Os objetos metadados são recursos criados e 
programados dentro de um SGDB (Sistemas Gerenciadores de Banco de Dados), 
podendo melhorar o desempenho e segurança dos sistemas. Além de utilizar o banco 
para armazenar os dados, também pode ser utilizado para programar toda regra de 
negócio da aplicação na camada de banco, consumindo menos recursos de rede entre as 
transações realizadas da camada de aplicação. 
Hoje em dia o conceito de banco de dados vem sendo amplamente utilizado em 
diversos projetos, inclusive para desenvolvimento de aplicações, implementando a 
lógica do negócio, segurança como controle de acessos, regras de negócio e outras 
funcionalidades no próprio banco de dados. Isso vem sendo possível com o avanço nos 
desenvolvedores, que vem agregando todas essas funcionalidades ao SGBD (SELLA, 
2010). 
Conforme mostrado na Figura 1a, as aplicações clientes que utilizam técnicas de 
programação incluídas na aplicação necessitamde mais tráfego de rede para execução 
de rotinas na base de dados, pois as regras de negócio (P1, U1, G1, R1) devem ser 
passadas ao SGBD sempre que uma instrução é necessária. Além disso, as regras devem 
ser incluídas em cada aplicação que as utiliza, tornando o processo de manutenção mais 
 
 
Página 10 
 
trabalhoso e complexo. Por outro lado, na Figura 1b, mostra-se um aplicativo cliente 
que tira vantagem de um procedimento armazenado, de uma função, de um gatilho ou 
ainda, com as restrições definidas diretamente no Banco. Isso pode ajudar a diminuir o 
tráfego de rede e o número de vezes que um banco de dados é acessado, pois há a 
redução de necessidade de interação, já que as regras estão no próprio servidor de banco 
de dados. Outra vantagem é que o código gerenciado pelo banco de dados é único e 
centralizado, ou seja, caso haja a necessidade de alterações nas regras, altera-se uma 
única vez, diferentemente das aplicações clientes, onde a mudança de regra deve ser 
realizada em todas as aplicações. 
Figura 1: Programação incluída na aplicação e no SGBD. 
 
Fonte: (SELLA, 2010) 
Os bancos de dados de objetos relacionais possuem uma diversidade de objetos e 
muitos desses objetos são indispensáveis ou vêm sendo cada vez mais utilizados pelas 
as aplicações. Segundo Spinola (2012): “Os objetos de banco de dados são conhecidos 
como unidades lógicas que compõe os blocos de construção do banco”. 
No banco de dados Oracle e também em outros bancos como, por exemplo: Mysql 
e SQLServer, esses objetos são conhecidos como sendo: tabelas (tables), visões (viwes), 
índices (indexes), gatilhos (triggers), restrições (constraints) como chaves primárias 
 
 
Página 11 
 
(primary keys) e chaves estrangeiras (foreign keys), procedimentos armazenados 
(storage procedure), funções (Functions), entre outros... 
À medida que esses objetos são criados no banco, há sempre uma necessidade de 
salvarmos em algum repositório para prevenir perdas ou erros que possam ser 
ocasionados, essas são medidas de segurança que o banco precisa, porque pode 
acontecer alguma falha de hardware ou até mesmo falha humana é assim podendo ter 
uma segunda alternativa para recuperação dos objetos. Muitas vezes os locais 
armazenados desses objetos fazem com que seja uma tarefa difícil a restauração. Neste 
cenário, a restauração deve ser feita por uma pessoa com conhecimento em 
administração de banco de dados, pessoa essa conhecida como DBA (Data Base 
Administrator). Assim, o desenvolvedor de sistemas pode não ter o conhecimento 
necessário em administração de banco ou simplesmente não possuir o acesso de DBA 
no banco em especifico. 
 Uma solução é criar um repositório no banco de dados capaz de capturar esses 
objetos automaticamente, na medida em que eles forem criados, ou alterados, sem a 
necessidade de uma pessoa que detenha/possua conhecimento em administração de 
banco de dados, podendo o próprio desenvolvedor ou pessoa com pouco conhecimento 
no assunto recuperar esses objetos através de uma interface gráfica que pode interagir 
com esse repositório. 
Hoje em dia, muitos sistemas gerenciadores de banco de dados oferecem rotinas 
de backup/recovery. A ORACLE (2014) desenvolveu a ferramenta recovery manager 
chamado RMAN para permitir o backup e a recuperação dos bancos de dados Oracle de 
forma automatizada. O Oracle também possui uma ferramenta para fazer exportação e 
importação lógica das informações de uma maneira mais rápida e flexível, conhecida 
como DATAPUMP, sendo que essa diferentemente do RMAN não é reconhecida como 
backup para o Oracle. Ambos os casos necessitam de um conhecimento técnico, 
geralmente essas ferramentas são sempre manuseadas pelo DBA da empresa. Em 
determinado momento pode acontecer de um desenvolvedor não ter como executar 
essas tarefas pelo fato de não ter o conhecimento ou até mesmo por não possuir os 
 
 
Página 12 
 
privilégios adequados para essa situação no qual somente o administrador de banco 
possui, podendo ele perder tempo no caso de precisar restaurar algum objeto metadado 
com problema. 
Com base nessa situação, a criação de um repositório no banco de dados Oracle 
pode facilitar para o desenvolvedor recuperar esses objetos metadados sem que haja a 
presença do próprio DBA e sem a necessidade de um conhecimento aprofundado do 
assunto. 
Prado (2012) desenvolveu um repositório para salvar os objetos metadados no 
banco de dados Oracle capaz de armazenar scripts DDL (Data Definition Language) e 
código procedimentais completo de cada objeto criado e sempre que houver uma 
atualização na sua definição ele irá contemplar o versionamento dos objetos desde a 
versão atual até versões anteriores utilizando a data de sua modificação para versionar. 
Para criar o repositório de metadados, é necessário ter um conhecimento amplo 
sobre o banco Oracle, pois a sua criação e configuração envolve o dicionário de dados 
do banco, além disso, para recuperar os objetos metadados salvos no repositório é 
preciso executar comandos SQL (Strutured Query Language) manualmente. Sendo 
assim, podemos concluir que ainda precisaria de um DBA ou pessoa com o 
conhecimento necessário, uma vez que a ideia é facilitar na recuperação desses objetos 
metadados sem que haja a presença da pessoa especifica no assunto, colaborando 
principalmente com o desenvolvedor que muitas vezes não trabalha diretamente com 
administração do banco de dados. 
1.1 Objetivos do Trabalho 
Desenvolver um repositório de metadados utilizando a base de conhecimento 
do mesmo repositório já desenvolvido por Prado (2012), e programar novas regras 
para facilitar sua usabilidade, a ponto de um desenvolvedor ou pessoa com pouco 
conhecimento do assunto, ser capaz de manuseá-lo a partir de uma interface gráfica. 
 
 
Página 13 
 
1.2 Objetivos Específicos 
 Estudar o banco de dados Oracle bem como as ferramentas de backup que ela 
possui e entender como os seus objetos metadados são criados, salvos e 
recuperados. A partir desse estudo será desenvolvido o repositório de metadados no 
banco de dados Oracle 11G. Também será desenvolvida uma interface gráfica a 
partir da ferramenta IDE (Integrated Development Environment) Delphi, que será 
encarregado de realizar todas as configurações e criação do repositório. 
1.3 Justificativa 
Muitas vezes é preciso fazer alterações rápidas nos objetos metadados para atender 
pedidos de melhoras em vários tipos de sistemas. Em diversas ocasiões pode acontecer 
dessas modificações não terem sido realizadas corretamente, acontecendo de o sistema 
parar de funcionar ou trabalhar de forma errada. 
Quando ocorrer esses problemas indesejados, é recomendado voltar à versão 
anterior do objeto metadado para que o sistema continue trabalhando corretamente e logo 
em seguida analisar a melhor forma de se aplicar a alteração solicitada. 
Em diversas ocasiões é necessário procurar por backups anteriores para recuperar 
os objetos metadados alterados, voltando a sua forma anterior. Isso pode acontecer pelo 
fato da sua alteração ter sido bastante complexa ou o próprio desenvolvedor ter 
esquecido a sua regra de origem. Com base nessa situação, começa a se criar um trabalho 
a mais, pois deve ser acionado o backup anterior, e depois seguir a procura do objeto 
modificado, é também comum que essa tarefa seja realizada por um DBA ou pessoa da 
área em especifico. 
Para melhorar esse processo, pode-se criar um repositório que armazene esses 
objetos metadados podendo o próprio desenvolvedor extrair qualquer código anterior 
criado ou alterado de um objeto, gastando menos tempo e custo, pois os objetos estarão 
 
 
Página 14 
 
organizados por data, de acordo com cada modificação feita e o repositório pode ser 
criado sem nenhum custo. 
1.4 Metodologia 
Com base no trabalho realizado por Prado (2012), foi construído o mesmo 
repositório e implantado novas regras a ele paraque possa facilitar ao desenvolvedor ou 
pessoa que atua na área em questão e que não tenha uma ampla visão sobre o banco de 
dados Oracle. Também foi desenvolvida uma interface para interagir com o repositório 
sem a necessidade da direta interação com o banco. 
Para desenvolver o repositório foi utilizado o banco de dados Oracle 11G, 
também pode estar utilizando as versões mais recentes a partir do Express, esse 
repositório não foi testado em outros bancos diferentes da Oracle por isso não deve 
funcionar em outras tecnologias. Foram criadas novas tabelas para estabelecer as regras 
dos tipos de objeto e de qual usuário em especifico for armazenado no repositório. O 
procedimento que é o mecanismo que interage com o dicionário de dados do banco 
Oracle e o repositório foram modificados e adaptados com as novas regras 
estabelecidas. Quando finalizado a criação do repositório, foi iniciado o 
desenvolvimento da interface gráfica que trabalha com esse repositório, podendo por ela 
realizar todas as configurações necessárias dentro do repositório, sendo: 
 Criar e configurar o tempo de execução do repositório; 
 Definir qual schema e tipos de objetos metadados que serão salvos no 
repositório; 
 Consultar e extrair o código dos objetos metadados por data de modificação; 
 Recompilar objetos do tipo: Procedimentos, Funções, Visões, Gatilho, entre 
outros... 
 
 
Página 15 
 
1.5 Estrutura do Trabalho 
Este trabalho está dividido em quatro capítulos: Introdução (Capítulo 1), 
Fundamentação Teórica (Capítulo 2), Desenvolvimento do Repositório (Capítulo 3) e 
Considerações Finais (Capítulo 4). 
No Capítulo 1, é apresentada uma introdução do que será o trabalho, definindo 
seus objetivos, apresentada a metodologia de desenvolvimento e estrutura do trabalho. 
No Capítulo 2, é feita toda fundamentação conceitual do trabalho e está dividida 
em nove itens principais: banco de dados, modelo de dados, linguagem SQL, objetos de 
banco, schema de banco, entendendo um repositório, conceitos de backup Oracle, 
Oracle PL/SQL e ferramenta de desenvolvimento Delphi. 
No Capítulo 3, é apresentada a estrutura e o desenvolvimento do repositório. 
Finalmente, no Capítulo 4, são apresentadas as considerações finais e 
recomendações sobre trabalho futuros. 
 
 
Página 16 
 
CAPÍTULO 2 
FUNDAMENTAÇÃO TEÓRICA 
______________________________________ 
Neste capitulo é apresentado o tema Banco de Dados descrevendo seu 
funcionamento e suas principais características, abordagem sobre objetos metadados, 
linguagem SQL, backup e recuperação de dados e a descrição das ferramentas utilizadas 
para implementação deste Trabalho de Conclusão de Curso (TCC), estando aqui 
relatados os temas Oracle Database e PL/SQL e a ferramenta de desenvolvimento 
Delphi a partir de livros, artigos, revistas e trabalhos anteriores. 
2.1 Banco de Dados 
Segundo Date (2004), um sistema de banco de dados é basicamente um sistema 
computadorizado de armazenamento de registros; isto é, um sistema computadorizado 
cujo propósito geral é armazenar informações e permitir ao usuário buscar e atualizar 
essas informações quando solicitado. As informações em questão podem ser quaisquer 
coisas que tenham significado para individuo ou a organização a que o sistema deve 
servir, em outras palavras, tudo que seja necessário para auxiliar no processo geral de 
tomada de decisões de negócio desses individuo ou dessa organização. O sistema de 
banco de dados envolve quatro componentes principais: Banco de dados, hardware, 
software, e usuários. Na Figura 2 são apresentados esses componentes, juntamente com 
o relacionamento entre eles. 
 
 
Página 17 
 
Figura 2: Componentes de um Sistema de Banco de dados. 
 
Fonte: (REZENDE, 2010) 
Segundo Oliveira (2000), o banco de dados da empresa Oracle teve sua história 
começando com o Dr. Ted Codd que em 1970 anunciou para o mundo o seu Modelo de 
Dados Relacional. Os melhores protótipos de Modelo de Dados Relacional feitos por 
Codd foram o System R e o Ingress, sendo que o primeiro era um sistema desenvolvido 
pelo laboratório de pesquisas San Jose da IBM e o outro por uma equipe liderada por 
Michael Stonebraker da Universidade de Berkeley na Califórnia. 
Um marco importante na época de 1970 foi a publicação no jornal de novas 
técnicas e dúvidas, sendo que o System R introduziu o SQL, a linguagem dos Bancos de 
Dados Relacionais que é referenciada como “padrão universal”. No tópico 2.3 deste 
trabalho este tema é detalhado. 
Segundo Oliveira (2000), na Califórnia quatro analistas de sistemas (Bob Miner, 
Ed Oates, Bruce Scott e Larry Ellison) após a leitura de trabalhos de Codd sobre o 
Ingress e o System R tiveram a brilhante idéia de fazer uma versão comercial do System 
R, a qual em 1977 gerou a Software Development Laboratories. 
Em 1979, o nome da companhia muda para Relational Software Incorporated 
(RSI) e neste momento foi criada a primeira versão comercial do Oracle o Oracle 
Version 2. O primeiro usuário Oracle foi a Base da Força Área de Wright Patterson, em 
novembro de 1979. 
 
 
Página 18 
 
Em 1983 o Oracle Version 3 é lançado o primeiro RDBMS a rodar em 
Mainframes e PC’s, sendo o sistema mais portável do mundo, neste mesmo ano o nome 
da empresa mudou de RSI para Oracle Corporation. 
Em 1997 a Oracle lança o Oracle 8 um sistema gerenciador de Banco de Dados 
Objeto-Relacional que comporta até 512 Petabytes de informação. Em 1999 surge o 
Oracle 8i que integra soluções de internet com Banco de Dados, que inclui 
significativas extensões orientadas a objetos que rodam direto no servidor como a 
PL/SQL. 
Conforme Blumm (2006), em 2006 a Oracle lança uma versão gratuita do seu 
banco de dados chamada Oracle 10G Express Edition a qual possui todas as 
funcionalidades e controles de um banco pago da Oracle sendo que só permite até 4 
Gigabytes de informação. 
2.2 Modelos de Dados 
De acordo com Date (2000), um modelo de dados é uma definição abstrata, 
autônoma e lógica dos objetos, operadores e outros elementos que, juntos constituem a 
máquina abstrata com a qual os usuários interagem. Os objetos permitem modelar a 
estrutura de dados. Os operadores permitem modelar seu comportamento. 
Segundo Oliveira (2000), o Modelo de Dados Relacional foi descrito pela 
primeira vez pelo matemático E. F. Codd , em um artigo de junho de 1970 intitulado “A 
Relational Model of Data for Large Shared Data Banks” (“Um Modelo Relacional de 
Dados para Grandes Bancos de Dados”). 
Os modelos mais utilizados na época eram os hierárquicos, de rede e estruturas de 
dados de arquivos planos, estes modelos apresentavam muita complexidade na 
manipulação e exigem um alto grau de manutenção das aplicações. 
 
 
Página 19 
 
O Modelo Relacional foi tão amplamente aceito no mercado, que proporcionou o 
advento dos programas chamado Sistemas de Gerenciamento de Banco de Dados 
Relacionais, ou RDBMS. 
Segundo Date (2000), as principais funções de um RDBMS são: 
 Flexibilidade: facilidade na definição da estrutura de armazenamento e na 
manipulação de dados; 
 Independência entre Dados e Programas: são os responsáveis por executar as 
tarefas solicitadas, o programador se preocupa apenas com a solicitação e 
manipulação dos dados; 
 Integridade de Dados: por ter embasamento matemático, tornou o Modelo 
Relacional preciso e consistente com os dados, eliminando a redundância 
desnecessária de informações. 
Em um modelo de dados tem a definição das estruturas das tabelas envolvidas no 
sistema abordado, gerando assim, uma fácil visualização de tudo que irá acontecer no 
sistema e qual a origem e destino dos dados da aplicação. 
2.3 Linguagem SQL 
Conforme Garcia, Ullman e Widom (2001), a linguagem de banco de dados SQL 
tem um grande número de recursos, inclusive instruções que consultam e modificam o 
banco de dados. A modificação do banco de dados é feita através de três comandos, 
chamadosINSERT, DELETE e UPDATE. Para a consulta do banco de dados é 
utilizado o comando SELECT. 
Segundo Oliveira (2000), quando os Bancos de Dados Relacionais estavam sendo 
desenvolvidos, foram criadas linguagens destinadas à sua manipulação. Após, vários 
modelos e versões surgirem no mercado em 1986 o American National Standard 
Institute (ANSI) publicou um padrão SQL que se estabeleceu como linguagem padrão 
de Banco de Dados Relacional. 
 
 
Página 20 
 
A SQL apresenta uma série de comandos que permite a definição dos dados, 
chamada DDL. Como exemplos de comandos da classe DDL, têm-se os comandos 
Create, Alter, Drop e Rename, conforme detalhados na Tabela 1. 
Tabela 1: Comandos DDL. 
Comando Função 
CREATE 
Utilizado para criar um novo objeto no banco de dados, como exemplo: 
tabelas, índices e visões. 
ALTER 
Utilizado para criar um novo objeto no banco de dados, como exemplo: 
tabelas, índices e visões. 
DROP 
Utilizado para remover um objeto do banco de dados, como exemplo: 
remover uma tabela, remover um índice, remover uma coluna ou mesmo 
remover as chaves de uma tabela. 
RENAME 
Utilizado para alterar o nome de um objeto do banco de dados, como 
exemplo: nome de colunas ou tabelas. 
Os comandos da série DML são destinados a consultas, inserções, exclusões e 
alterações em um ou mais registros de uma ou mais tabelas de maneira simultânea. 
Como exemplo de comandos da classe DML, têm-se os comandos Select, Insert, 
Update, Delete, Commit e Rollback, conforme detalhados na Tabela 2. 
Tabela 2: Comandos DML. 
Comando Função 
SELECT 
É o principal comando da linguagem, como ele é possível recuperar 
dados de uma tabela ou de uma visão. 
INSERT 
Insere linhas em uma tabela. 
UPDATE 
Altera o conteúdo de colunas de uma tabela. 
DELETE 
Exclui linhas de uma tabela. 
 
 
Página 21 
 
COMMIT 
Efetiva todas as transações realizadas e não pendentes de efetivação da 
sessão para o banco de dados. Após este comando ser executado outras 
sessões passam a visualizar os dados inseridos ou manipulados nesta 
sessão. 
ROLLBACK 
Desfaz todas as modificações efetuadas na sessão desde o último commit. 
Qualquer dado inserido ou manipulado que esteja ainda não efetivado 
pelo uso do comando commit será excluído da sessão, não tendo mais 
como recupera-lo. 
A DCL que é uma subclasse de comandos DML, dispõe de comandos de controle 
como Grant e Revoke, conforme detalhados na Tabela 3. 
Tabela 3: Comandos DCL. 
Comando Função 
GRANT 
O propósito do comando é ceder privilégios. Tem-se dois tipos de 
privilégio: sobre os objetos e de sistemas, que autorizam determinadas 
ações dos usuários no banco de dados. 
REVOKE 
Retira privilégios previamente fornecidos, tanto de sistemas quanto de 
objetos. 
Outra característica interessante na linguagem SQL é a capacidade que dispõe de 
cancelar uma série de atualizações ou de efetivar, depois de iniciar uma sequência de 
atualizações. Os comandos Commit e Rollback são responsáveis por estas facilidades. 
Um ponto importante é que a linguagem SQL consegue implementar estas 
soluções, somente pelo fato de estar baseada em Banco de Dados Relacional que 
garantem por si mesmo a integridade das relações existentes entre as tabelas e seus 
índices. 
2.4 Objetos de banco de dados 
De acordo com Spinola (2012) “Um objeto de banco de dados se refere a qualquer 
objeto que é utilizado para armazenar ou referenciar dados”. Alguns exemplos destes 
objetos são: 
 
 
Página 22 
 
 Tabela (table): é a unidade básica de armazenamento de dados sendo composta 
por linhas e colunas; 
 Visão (view): logicamente representam subconjuntos de uma ou mais tabelas e 
se comportam como tabelas quanto à inserção, alteração, exclusão e consulta 
de dados, ou seja, pode-se inserir, alterar, excluir ou consultar dados em uma 
view, respeitando sempre as regras de integridade e de segurança que 
estiverem definidas sobre as tabelas envolvidas na constituição da view; 
 Índice (indexe): é um objeto de banco de dados de um schema que pode 
acelerar o acesso e a recuperação de linhas em uma tabela através do uso de 
ponteiros, provendo assim um acesso direto e rápido às linhas da tabela; 
 Restrição (constraint): correspondem a uma regra de integridade aplicada 
sobre uma determinada tabela. A constraint é definida e mantida no banco de 
dados Oracle. Em linhas gerais, constraints, são utilizadas para prevenir 
entrada inválida de dados nas tabelas. Ou seja, implementam regras a nível de 
tabela que são verificadas toda vez que uma linha é inserida, alterada ou 
excluída na tabela; 
 Gatilho (trigger): é um conjunto de comandos PL/SQL que são executados 
quando se realiza uma inserção, alteração e/ou exclusão em uma tabela. A 
trigger é executada (disparada) antes da consumação da operação sobre a 
tabela. Se, por algum motivo, a execução da trigger não for completada, a 
operação sobre a tabela também não é. Por isso mesmo, geralmente se utiliza 
triggers para implementar regras de integridade complexas e que por isso não 
podem ser implementadas por constraints. Também são utilizadas para 
execução de ações diversas desencadeadas pela operação de inserção, alteração 
ou exclusão sobre a tabela; 
 Procedimento armazenado (Stored Procedure): é uma coleção de comandos 
em SQL. Encapsula tarefas repetitivas, aceita parâmetros de entrada e retorna 
um valor de status (para indicar aceitação ou falha na execução). O 
 
 
Página 23 
 
procedimento armazenado pode reduzir o tráfego na rede, visto que os 
comandos são executados diretamente no servidor. Além de melhorar o 
desempenho, cria mecanismos de segurança entre a manipulação dos dados do 
banco. 
2.5 Schema de banco 
Segundo Spinola (2012), “Um schema é uma coleção de objetos de banco de 
dados normalmente associada a um usuário de um banco de dados em particular, este 
usuário é mais conhecido como dono do schema”. Você pode ter um ou 
mais schemas em um banco de dados. Qualquer usuário que crie um objeto no banco de 
dados está criando este objeto automaticamente em seu próprio schema a não ser que o 
usuário defina explicitamente que aquele objeto deva fazer parte de outro schema. Desta 
forma, baseado nos privilégios que o usuário possui no banco de dados, ele poderá 
controlar um conjunto de objetos através de comandos de criação, manipulação e 
deleção de objetos. A figura abaixo ilustra dois esquemas em um banco de dados 
relacional. 
Figura 3: Schemas em um banco de dados. 
 
Fonte: o próprio autor. 
 
 
Página 24 
 
2.6 Entendendo um Repositório de Metadados 
De acordo com Prado (2012), Para entender a estrutura do repositório, é preciso 
entender primeiro o que é o repositório de metadados. O Repositório de Metadados é o 
local onde serão armazenados os scripts DDL (Data Definition Language) de criação 
dos principais objetos do BD (banco de dados). Este repositório irá contemplar o script 
DDL completo de cada objeto sempre que houver uma mudança na sua definição, ou 
seja, ele irá contemplar o versionamento dos objetos. O banco de dados contém somente 
a versão atual de cada objeto. O repositório conterá além da versão atual, versões 
anteriores. Os principais benefícios de implementar este repositório são: 
 Versionamento dos objetos do banco de dados: a partir da implantação do 
repositório, todo dia será gerada uma cópia (versão) dos objetos que foram 
alterados; 
 Permite detectar mudanças nos objetos do banco de dados: no procedimento 
que faz o versionamento você pode acrescentar rotinas para enviar notificações 
(como, por exemplo, um e-mail informativo) sempre que ocorrerem mudanças 
nos objetos do banco; 
 Permite recuperações mais rápidas de versões anteriores dos objetos do banco 
de dados: você poderá recuperar qualquer versão anterior, gravada no 
repositório, de objetos do banco. Se você tivesse que recuperar uma stored 
procedure, por exemplo, a partir de um backup,o tempo de restauração seria 
muito maior. Se você precisar recuperar uma versão de 10 anos atrás de um 
objeto, você conseguirá fazer isso facilmente através do repositório. Através de 
um backup, é bem provável que você não consiga fazer esta recuperação, pois 
dependendo da política de backup da empresa, você não terá acesso às fitas de 
backup de 10 anos atrás; 
 Permite recuperações mais fáceis: para recuperar objetos contidos no 
repositório é necessário apenas ter conhecimentos básicos de instruções SQL; 
 
 
Página 25 
 
2.7 Conceitos de backup e recuperação de dados Oracle 
Segundo a ORACLE (2014), os principais deveres de um administrador de banco 
de dados Oracle, é conceder, implementar, gerenciar um backup e recupera-lo 
estrategicamente no banco de dados. Em geral, o propósito de uma estratégia de backup 
e recuperação é proteger a base de dados contra a perda de dados e reconstruir o banco 
de dados após a perda. Normalmente, as tarefas de administração de backup incluem os 
seguintes conceitos: 
 Planejamento de testes para obter respostas a diversos tipos de falhas; 
 Configuração do ambiente de banco de dados para backup e recuperação; 
 Configurar um agendamento de backup; 
 Acompanhar o ambiente de backup e recuperação; 
 Definir soluções de problemas para o backup; 
 Recuperando-se de perda de dados em caso de necessidades; 
No banco de dados Oracle, a cópia de segurança de um backup pode ser utilizado 
para construir os dados com informações referentes ao tempo anterior que foi executado 
o backup. Um backup Oracle pode ser conhecido como: físico ou lógico. 
Backups físicos são cópias dos arquivos físicos que constitui no banco de dados 
utilizados no armazenamento e recuperação de um banco. Esses arquivos incluem: 
Arquivos de dado (data files), Arquivos de controle (control files) e Redo logs. Em 
última análise, cada backup físico é uma copia dos arquivos que armazenam 
informações de banco de dados para outro local, seja em disquete ou em suportes de 
armazenamento offline, como fitas. 
Backups lógicos contem dados, tais como tabelas e procedimentos armazenados. 
Pode-se utilizar o Oracle Data Pump para exportar dados lógicos em arquivos binários, 
que mais tarde o mesmo arquivo pode ser importado para o banco de dados. 
 
 
Página 26 
 
A Oracle possui também a solução de backup RMAN (Recovery Manger). O 
Rman é a ferramenta recomendada pela Oracle para ser realizado as tarefas de backup, 
sendo que ela é totalmente integrada com o banco de dados. Para utilizar o Rman, você 
precisa executar operações de backup e recuperação utilizando uma mistura de 
comandos do sistema operacional hospedeiro e SQL. 
Outra ferramenta também disponibilizada pela Oracle desde a versão 9i é a 
Flashback. Desde o lançamento, foram desenvolvidos oito diferentes tipos de 
Flashback, considerando os lançados até sua versão atual, Oracle 11g. Na Tabela 4 
estão descritos cada tipo de flashback existente de acordo com a versão em que foi 
lançado. 
Tabela 4: Diferentes tipos de Flashback por versões do Oracle. 
Versão Tipo de Flashback Descrição 
Oracle 
9i 
Flashback Query Fornece a capacidade de visualizar os dados em um 
determinado ponto no tempo, especificando uma data ou 
um System Change Number (SCN). 
Oracle 
10g 
Flashback 
Database 
Provê uma alternativa rápida e eficiente para recuperar o 
banco de dados até um tempo passado. Flashback 
Database retorna rapidamente um banco de dados para um 
momento anterior, corrigindo assim eventuais problemas 
causados por dados corrompidos ou erros humanos. 
Flashback Drop Esta funcionalidade permite recuperar uma tabela apagada. 
Quando um usuário “dropa” uma tabela, o Oracle 
automaticamente a coloca na lixeira. 
Flashback Table Retorna uma tabela para um determinado ponto no tempo, 
especificando uma data ou um SCN. Com o Flashback 
Table o DBA é capaz de recuperar uma ou mais tabelas de 
maneira rápida, fácil e on-line. 
Flashback 
Transaction Query 
Permite visualizar e retornar os comandos realizados em 
uma única transação, ou em todas as transações durante um 
período de tempo. 
Flashback Version 
Query 
Permite visualizar todas as versões de todas as linhas que já 
existiu em uma ou mais tabelas em um determinado 
intervalo de tempo. 
Oracle 
Flashback Data 
Archive 
Utilizado para monitorar e manter um histórico das 
alterações ocorridas nos dados do banco, de forma 
transparente, segura e eficiente. 
 
 
Página 27 
 
11g Flashback 
Transaction 
Backout 
Esta é uma extensão do Flashback Transaction 
Query introduzida no banco de dados Oracle 10g. Esta 
funcionalidade permite que o DBA retorne o banco uma ou 
mais transações. 
2.8 Oracle PL/SQL 
De acordo com Oliveira (2000), o PL/SQL permite a utilização direta de 
comandos SQL dentro do código e oferece também um mecanismo eficiente de 
tratamento de erros. O código PL/SQL utilizado para interagir com o Banco de Dados, 
também é armazenado no próprio Banco de Dados. É a única linguagem que oferece 
uma interface de acesso nativo ao Oracle e que esta situada dentro do próprio ambiente 
Oracle. 
Os módulos de código PL/SQL são divididos em quatro categorias: 
 package (pacote): Uma coleção de procedures e functions que tem duas partes. 
Uma composta por uma lista com as disponíveis no pacote, e outra, uma parte 
de implementação, que consiste no código fonte de cada uma delas; 
 procedure (procedimentos): Uma série de comandos que aceitam e retornam 
zero ou mais variáveis; 
 function (funções): Uma série de comandos que aceitam zero ou mais variáveis 
que retornam um valor; 
 trigger (gatilho): Uma série de comando PL/SQL que é associada a uma tabela 
no Banco de Dados. O gatilho sempre é executado quando um evento ocorre 
sobre a tabela-alvo (uma operação select, insert, update ou delete ). 
2.9 Delphi 
De acordo com GAJIC (2011), a ferramenta Delphi é uma interface integrada 
(IDE) e é usado para o desenvolvimento de sistemas de inúmeras áreas de atuação. Ele 
 
 
Página 28 
 
foi desenvolvido através da linguagem Object Pascal, e é uma ferramenta do tipo RAD 
(Rapid Application Development) de fácil utilização. Possui um ambiente de 
desenvolvimento integrado onde é possível: editar código, testar a aplicação 
desenvolvida, verificar erros e retornar até a linha com problemas, além de compilar a 
aplicação para execução no sistema operacional. 
A linguagem de programação Object Pascal utilizada para criação do Delphi, deve 
muito, ao antigo projeto ALGOL, que foi a primeira linguagem de programação de alto 
nível, com estrutura legível, e uma sintaxe sistematicamente desenvolvida. O Pascal era 
uma linguagem de programação criada pelo Professor Niklauss Wirth, com o objetivo 
de ser uma ferramenta para praticar e criar algoritmos. A definição original de Pascal 
surgiu em 1971, sendo implementado em 1973 com algumas modificações. 
Em 1983 a Borland criou o Turbo Pascal 1.0, que era uma IDE (que é um 
ambiente de desenvolvimento, com compilador e ferramentas de detecção e correção de 
erros). A partir do Turbo Pascal, a Borland em 1995 lançou a primeira versão do 
Delphi, que era um ambiente de desenvolvimento rápido de aplicações RAD (do inglês 
Rapid Application Development, que significa desenvolvimento rápido de aplicações), 
tornando o pascal uma linguagem de programação visual, com o intuito de facilitar a 
conectividade com bancos de dados. 
 
 
Página 29 
 
CAPÍTULO 3 
DESENVOLVIMENTO DO REPOSITÓRIO 
______________________________________ 
Neste capítulo é apresentado o desenvolvimento do repositório, através do 
levantamento dos requisitos, especificações, implementação do repositório com o banco 
de dados Oracle e Pl/SQL, e o desenvolvimento da interface gráfica. 
3.1 Descrição do Ambiente 
Abaixo e apresentado à estrutura física e logica utilizada para desenvolver o 
repositório. 
3.1.1 EstruturaFísica 
 1 Notbook Intel Corei5, 4GB de RAM. 
 1 Maquina Desktop Intel Corei5, 4GB RAM. 
 Modem ADSL. 
 Roteadores. 
3.1.2 Estrutura logica 
 Sistema Operacional Windows 7 e Oracle Linux 6. 
 Banco de Dados Oracle 11G. 
 Client Oracle 11. 
 PL/SQL. 
 Delphi 7. 
 Gerador de Diagramas (Enterprise Architect). 
 
 
Página 30 
 
3.2 Visão Geral do Repositório 
O desenvolvimento do repositório utiliza os próprios recursos que o banco de 
dados Oracle possui. Alguns desses recursos são: objetos metadados, dicionário de 
dados e agendador de tarefa. A seguir e apresentado como cada recurso foi utilizado. 
3.2.1 Objetos Metadados 
Os objetos metadados são recursos criados e programados dentro de um SGDB 
(Sistemas Gerenciadores de Banco de Dados), podendo melhorar o desempenho e 
segurança dos sistemas, além de utilizar o banco para armazenar os dados. No banco de 
dados Oracle foram criados três objetos do tipo table uma para armazenar as 
configurações dos usuários e outra de tipos de objetos de cada usuário a ser salvos na 
tabela de repositório. Foi criado um objeto do tipo procedure que é o motor do 
repositório onde realiza todo trabalho de consultar as alterações dos objetos metadados 
através do dicionário de dados do Oracle e salvar no repositório. 
3.2.2 Dicionário de Dados 
O dicionário de dados do banco Oracle, disponibiliza uma série de recursos capaz 
de monitorar e auditar todas as informações do banco. Para este caso foi utilizado um 
objeto do tipo view do dicionário de dados conhecido como sysobject, esse objeto é uma 
visão capaz de identificar as últimas modificações dos objetos metadados para serem 
armazenados no repositório através do versionamento da ultima data de alteração. 
3.2.3 Agendamento de Tarefa 
Conhecido no banco de dados Oracle como job esse recurso proporciona o 
funcionamento automatizado do repositório, com ele é possível utilizar o tempo 
 
 
Página 31 
 
desejado para execução do repositório podendo ser configurado um período de tempo 
em dias, horas, minutos e segundos. 
3.2.4 Interface Gráfica 
Por final foi construído uma interface gráfica com a ferramenta Delphi, que é 
utilizada para consultas, alterações e configurações do repositório facilitando no 
manuseio do repositório. 
3.3 Passos para Criação do Repositório 
A seguir é detalhado cada passo para construção do repositório que está sendo 
apresentado na Figura 4: 
 No passo 1, foi instalado e configurado o banco de dados Oracle. 
 No passo 2, após a criação do banco de dados foi criado um usuário (schema 
de banco) e definido os privilégios para acesso no banco com esse usuário. 
 No passo 3, foram criados tabelas no banco de dados onde armazena o nome 
de usuários, tipos de objetos desses usuários e a tabela de repositório que 
armazena os objetos metadados. Com essas tabelas criadas são realizadas 
consultas na tabela usuários e tipos de objetos e caso retorne resultado de 
objetos metadados, então salva na tabela de repositório. 
 No passo 4, foi criado o procedimento que envolve o mecanismo de consultas e 
inserções de dados nas tabelas (criadas no passo 3), juntamente com o 
dicionário de dados do banco Oracle. 
 No passo 5, é criado uma JOB padrão que executa o procedimento do passo 4, 
automatizada. 
 No passo 6, é desenvolvido uma interface gráfica para ser realizado todas 
configurações do repositório. 
 
 
Página 32 
 
Figura 4: Passos para construção do Repositório. 
 
Fonte: o próprio autor. 
3.4 Requisitos do Repositório 
Com o levantamento de requisitos é possível identificar quais são os passos a 
serem tomados para conseguir chegar à solução desejada. A seguir são relacionados os 
Requisitos Funcionais (RF) e os Requisitos Não funcionais (RNF) do repositório. 
 O administrador de banco de dados deverá criar o usuário de banco e conceder 
os privilégios necessários para acesso da interface no repositório (RF); 
 O repositório deve ser criado no primeiro acesso pela interface gráfica (RF); 
 Permitir ao desenvolvedor escolher quais usuários e tipo de objetos que serão 
salvos no repositório pela interface (RF); 
 Deve possibilitar ao desenvolvedor configurar o agendamento de backup no 
tempo em que desejar pela interface (RF); 
 
 
Página 33 
 
 Permitir fazer consultas nos objetos salvos por tipo de objeto ou pelo nome 
pela interface (RF); 
 Permitir realizar a recompilação dos objetos do tipo: pakage, procedure, 
function e trigeer pela interface (RF); 
 Utilizar o banco de dados Oracle 10G ou superior (RNF); 
 Executar a interface gráfica em um sistema operacional Windows (RNF); 
 Para interface comunicar com o banco de dados o sistema operacional deve 
conter um cliente da Oracle (RNF). 
3.5 Especificação 
A especificação do repositório foi feita utilizando diagramas de UML através da 
ferramenta Enterprise Architect para desenvolvimento dos casos de uso e a utilização da 
ferramenta PL/SQL Developer para criação do modelo relacional. 
3.5.1 Diagrama de Caso de Uso 
É apresentado na Figura 5 o diagrama de caso de uso do administrador de banco 
de dados para configuração do ambiente de banco para o Repositório. 
Figura 5: Diagrama de Caso de Uso do DBA. 
 
Fonte: o próprio autor. 
 
 
Página 34 
 
A seguir é apresentada a especificação para cada uso: 
 UC01 – O DBA configura o ambiente de banco de acordo com as 
especificações da Oracle. 
 UC02 – O DBA cria o usuário de banco e define uma senha de acesso para 
acesso usuário. Nesse usuário vai ficar armazenado toda estrutura do 
Repositório. 
 UC03 – O DBA atribui uma série de privilégios para o usuário acessar e criar o 
Repositório no Banco de Dados. 
É apresentado na Figura 6 o diagrama de caso do desenvolvedor do Repositório 
de Metadados. 
Figura 6: Diagrama de Caso de Uso do Desenvolvedor. 
 
Fonte: o próprio autor. 
A seguir é apresentada a especificação para cada uso: 
 UC01 – O Desenvolvedor deve entrar no repositório pela interface gráfica, 
especificando o nome do banco, usuário e senha. Deve conter o cliente do Banco 
de Dados Oracle para acesso. 
 UC02 – O Desenvolvedor acessa o módulo de configurações/Backup e define 
quais usuários e tipos de objetos deveram ser armazenados no Repositório. 
 
 
Página 35 
 
 UC03 – O Desenvolvedor acessa o módulo de configurações/Agendador e 
define o tempo de execução do Repositório. Pode ser especificado por: dia, mês 
ano, hora e minuto ou ainda, por um intervalo de tempo. 
 UC04 – O Desenvolvedor consulta e recupera os Objetos Metadados de 
determinado usuário que ele especificar nas configurações de backup. 
3.5.2 Diagrama de Atividades 
O diagrama de atividades do repositório, e apresentado na Figura 7. 
Figura 7: Diagrama de Atividades. 
 
Fonte: o próprio autor. 
 
 
Página 36 
 
A seguir é apresentada a especificação do diagrama de atividades do repositório 
seguindo do inicio: 
 
 O DBA instala e configura o banco de dados utilizando as especificações do 
repositório. 
 Já com o cliente instalado no sistema operacional, o desenvolvedor conecta no 
repositório pela interface gráfica. 
 Acessando a interface gráfica, no primeiro acesso pela interface, é apresentada 
uma mensagem dizendo que vai ser instalado o repositório. 
 Caso for o primeiro acesso, será instalado o repositório automaticamente e em 
seguida a interface gráfica e aberta. 
 Se não for o primeiro o acesso à etapa de criação do repositório não e mais 
solicitada e a interface e aberta. 
 Com a interface aberta, deve ser feito a configuração da execução do repositório 
e especificar oque deseja ser trabalhado com o repositório sendo usuário e 
objetos metadados. 
 Com o repositório pronto e executando, já pode ser utilizado para consultar e 
recuperar os objetos metadados que deseja. 
 
3.5.3 Modelo de Dados Relacional 
O modelo de dados relacional foi construído na ferramenta PL/SQL developer 
cujofabricante é a empresa AllroundAutomations. Na Figura 8 e apresentada às 
entidades do modelo de dados relacional utilizado pelo repositório. 
 
 
Página 37 
 
Figura 8: Modelo de dados Relacional das Entidades. 
 
Fonte: o próprio autor. 
A seguir uma breve descrição das entidades utilizadas para desenvolvimento do 
repositório. 
 usuarios_repo: entidade responsável por armazenar e controlar os usuários de 
banco de dados incluso no repositório e que são especificados os seus 
respectivos objetos na entidade objeto_repo; 
 objeto_repo: entidade responsável por armazenar os tipos de objetos metadados de cada 
usuário inserido na entidade usuarios_repo, e que vai ser utilizado pelo repositório; 
 configura_job_repo: entidade responsável por armazenar as configurações de tempo do 
agendamento de backup do repositório. 
 repository_metadata: entidade responsável por salvar, controlar e restaurar os objetos 
metadados. Essa entidade é onde estão guardados os objetos metadados de cada usuário 
especificado nas entidades usuarios_repo e objeto_repo. 
 
 
Página 38 
 
3.5.4 Dicionário de Dados do Repositório 
O dicionário de dados de cada entidade do modelo de dados relacional encontra-se 
nas tabelas de 5 a 8. Os tipos de dados dos campos tem alguma características 
especificas: 
 O tipo de dado VARCHAR2 é um campo que armazena caracteres CHAR, mas 
com limitações. 
 O tipo de dado NUMBER é um campo que armazena somente números podendo 
conter precisão para utilizar números reais. 
 O tipo de dado DATE que é um campo que armazena somente data, composta 
por século, dia, mês, ano, hora, minuto e segundo. 
 O tipo de dado CLOB é um campo que armazena dados baseados em caracteres 
Unicode, como grandes textos com qualquer conjunto caracteres. 
Tabela 5: Dicionário de Dados da Entidade usuarios_repo. 
Campo Descrição Tipo 
COD_USUARIO 
Cada usuário selecionado na configuração do 
repositório e gerado um código único sequencial 
começando em 1. 
NUMBER 
NOME_USUARIO 
Armazena o nome do schema de banco escolhido para 
salvar seus respectivos objetos metadados. 
VARCHAR2 
Tabela 6: Dicionário de Dados da Entidade objeto_repo. 
Campo Descrição Tipo 
COD_OBJETO 
Cada tipo de objeto selecionado por usuário na 
configuração do repositório e gerado um código único 
sequencial começando em 1. 
NUMBER 
TIPO_OBJETO 
Armazena o nome do tipo do objeto escolhido por 
usuário. 
VARCHAR2 
COD_USUARIO 
Faz referencia com a entidade usuarios_repo, o usuário 
que foi escolhido na configuração e armazenado seu 
código nesse campo para saber qual objeto por usuário 
deve ser salvo no repositório. 
NUMBER 
 
 
Página 39 
 
Tabela 7: Dicionário de Dados da Entidade configura_job_repo. 
Campo Descrição Tipo 
DTA_INICIO 
Armazena a data que iniciara a execução do 
repositório. 
DATE 
SEMANA 
Armazena os dias da semana que deve ser executado, 
Ex: Domingo, segunda, terça, quarta, quinta, sexta e 
sábado. 
VARCHAR2 
FREQUENCIA 
E armazenado a frequência, sendo que são três tipos: 
diariamente, por hora ou por minuto. 
VARCHAR2 
INTERVALO 
Armazena o intervalo de tempo, o padrão e 0 que e 
igual a sem intervalo. Ex: se foi selecionado a 
frequência diariamente e o intervalo for colocado em 1 
então dia sim e dia e executado o repositório. 
CHAR 
HORA 
Armazena a hora que iniciara a execução. CHAR 
MINUTO 
Armazena o minuto que iniciara a execução. CHAR 
Tabela 8: Dicionário de Dados da Entidade repository_metadata. 
Campo Descrição Tipo 
TX_OBJECT_DDL 
Armazena o código fonte de cada objeto metadados. CLOB 
NM_SCHEMA 
Armazena o nome do schema vinculado ao objeto 
metadados. 
VARCHAR2 
NM_OBJECT 
Armazena o nome do objeto metadados criado no 
banco. 
VARCHAR2 
DT_LAST_UPDAT
E 
Armazena a data da ultima modificação realizado no 
objeto metadados dentro do banco de dados. 
DATE 
DS_OBJECT_TYP
E 
Armazena o tipo do objeto metadados. VARCHAR2 
DT_INSERT_REG 
Armazena a data de inserção do objeto metadados no 
repositório. 
DATE 
 
 
Página 40 
 
Além das entidades, o dicionário de dados do repositório e composto por uma 
procedure chamada de (prc_repositorio_metadados) que é o mecanismo que realiza 
toda interação com o banco de dados e o repositório realizando consultas nas visões do 
banco Oracle e nas entidades já descritas, armazenando os objetos dentro do repositório. 
Essa procedure e executada por uma job chamado de (job_repo) croado no banco 
Oracle. Na criação do repositório essa job e atribuída com valores padrões. Nas tabelas 
de 9 a 10 e apresentado os recursos que compõe a estrutura da procedure e job. 
Tabela 9: Dicionário de Dados da Procedure prc_repositorio_metadados. 
Recursos utilizados Descrição TIPO 
S_DDL 
Utilizada para receber o código dos objetos 
metadados capturados no banco. 
VARIAVEL 
 
EXISTE 
Variável utilizada para verificar se o objeto 
armazenado no repositório foi modificado ou não. 
VARIAVEL 
SYS.OBJ$ 
Consultar todos os objetos criados no banco de 
dados. 
TABELA 
SYS.ALL_USERS 
Consultar todos os usuários criados no banco de 
dados. 
VIEW 
SYS.DBA_OBJECTS 
Descrever todos objetos e tipos de objetos do banco, 
se ele esta valido ou não. 
VIEW 
REPOSITORY_MET
ADATA 
Utilizado pelo repositório no armazenamento dos 
objetos metadados. 
TABELA 
USUARIOS_REPO 
Consulta os usuários selecionados pelo repositório 
para ser salvos seus objetos. 
TABELA 
OBJETO_REPO 
Consulta os objetos selecionados de cada usuário do 
repositório que deve ser salvo. 
TABELA 
Tabela 10: Dicionário de Dados da job job_repo. 
Atributos Descrição 
DBMS_SCHEDULER 
Pacote do banco de dados Oracle utilizado para criar a job através 
da do procedimento create_job. 
JOB_TYPE 
Atribui o tipo do programa a ser executado, nesse caso e utilizado 
“PL/SQL Block”. 
 
 
Página 41 
 
JOB_ACTION 
Chama a procedure prc_repositorio_metadados através para ser 
executado. 
START_DATE 
Atribui a data desejada para inicio da execução da procedure. 
REPEAT_INTERVAL 
Atribui à frequência de execução em dias, horas e minutos. 
3.6 Implementação 
A seguir são apresentadas as técnicas e ferramentas utilizadas e a 
operacionalidade da implementação do repositório e demonstração do uso pela interface 
gráfica. Não serão apresentadas as técnicas utilizadas para construção da interface 
gráfica, pois o foco desse trabalho e demonstrar como é construído o repositório. 
3.6.1 Técnicas e ferramentas utilizadas 
O desenvolvimento do repositório foi feito por meio do software PL/SQL, que 
permite a criação de objetos metadados além de realizar consultas e modificações em 
dados contidos no banco de dados através da linguagem SQL. 
O banco de dados utilizado pela ferramenta foi o Oracle 11g Express Edition, que 
é distribuído gratuitamente pela empresa Oracle para estudantes e também para 
desenvolvedores de pequeno porte, pois essa versão tem suas limitações de uso. 
A criação da estrutura do repositório foi embutida na interface gráfica para ser 
construído no primeiro acesso pelo usuário. Dessa forma não é preciso se preocupar em 
construí-lo manualmente. 
3.6.2 Arquitetura 
Nesta sessão são apresentadas as telas para criação e utilização do repositório pela 
interface. 
 
 
Página 42 
 
Após a instalação e configuração do banco de dados pelo DBA, o primeiro passo 
para a criação do repositório é criar o usuário no banco de dados e atribuir os privilégios 
necessários. Na Figura 9 é apresentada a criação do usuário utilizando a ferramenta 
PL/SQL e acessando o banco através do usuário “system”, sendo esse usuário utilizado 
pela Oracle na instalação do banco de dados. 
Figura 9: Criando usuário no banco pela ferramenta PL/SQL. 
 
Fonte: o próprio autor. 
Após a criação do usuário, deve-se conectar no banco através da interface gráfica 
com o usuário criado para que seja criada a estrutura do repositório. Na Figura 10 é 
apresentada a tela da interfacegráfica que realiza conexão com o banco de dados. 
Figura 10: Conectando no banco de dados pela interface gráfica. 
 
Fonte: o próprio autor. 
 
 
Página 43 
 
Para realizar a conexão com o banco de dados pela interface gráfica, é necessário 
instalar um Cliente Oracle no sistema operacional e configurar sua conexão com o 
banco. Devem ser preenchidos os campos conforme mostra a Figura 10, especificando o 
nome correto do banco contido na conexão do Cliente, utilizar o nome do usuário 
padrão “usr_repo” e a senha definida. 
No primeiro acesso ao repositório pela interface gráfica, ao pressionar o botão 
conectar, será emitido uma mensagem para criação do repositório conforme apresentado 
na Figura 11. 
Figura 11: Criando Repositório no primeiro acesso. 
 
Fonte: o próprio autor. 
Pressionando o botão “OK”, será emitida uma nova mensagem confirmando que o 
repositório foi criado com sucesso conforme mostra a Figura 12. 
Figura 12: Confirmação de criação do Repositório. 
 
Fonte: o próprio autor. 
 
 
Página 44 
 
Pressionando-se o botão “OK” novamente será aberta a interface gráfica do 
repositório, conforme apresentado na Figura 13. O procedimento de criação do 
repositório está assim concluído e não será mais solicitado no próximo acesso. caso se 
desejar recriar o repositório, torna-se necessário recriar o usuário “usr_repo”. 
Figura 13: Interface gráfica. 
 
Fonte: o próprio autor. 
Na Figura 13 é ilustrada a tela principal da interface gráfica. Nessa tela são 
realizadas as consultas dos objetos metadados contidos no repositório. Na parte 
esquerda da tela é possível visualizar os objetos que constam no repositório através de 
pesquisa por tipo de objeto, nome ou usuário (schema). Na parte direita é visualizado o 
código fonte do objeto selecionado, e abaixo contém um botão que é possível 
recompilar determinados tipos de objetos. 
Para iniciar a execução do repositório, deve ser configurado o backup, ou seja, 
devem ser especificados quais usuários e tipos de objetos que serão utilizados pelo 
repositório e em seguida configurado o agendamento de execução. Na Figura 14 e 
apresentado o acesso ao menu para configuração de backup. 
 
 
Página 45 
 
Figura 14: Acessando menu configuração. 
 
Fonte: o próprio autor. 
Quando selecionar o menu backup será aberta tela apresentada na Figura 15. 
Nessa tela é realizada a configuração dos objetos que deseja que o repositório faça 
backup. No entanto, é necessário especificar qual usuário contido no banco de dados 
que deseja utilizar. Em seguida, devem ser selecionados os tipos de objetos metadados 
do lado esquerdo e transferidos para o lado direito, conforme apresentado para os tipos 
table e procedure. 
Figura 15: Configurando backup do Repositório. 
 
Fonte: o próprio autor. 
Após finalizar a configuração de usuários e objetos metadados, é necessário 
fechar a tela e acessar novamente o menu configuração apresentado na Figura 14, 
escolhendo-se o item “agendador”, cuja tela está ilustrada na Figura 16. 
 
 
Página 46 
 
Figura 16: Configurando agendamento de backup do Repositório. 
 
Fonte: o próprio autor. 
No agendamento de backup devem ser determinados a data de inicio da exeução, 
os dias das semanas, a frequência em três modos, sendo: Diário, Por hora ou Minuto e 
escolher o horário do dia que vai ser iniciado a execução. Essa configuração deve ser 
realizada de acordo com as necessidades de cada usuário. Ao pressionar o botão 
“Aplicar”, o Repositório começa a trabalhar no tempo que foi especificado. 
Quando o agendamento mandar executar o repositório, vão ser armazenados os 
objetos metadados do schema que foi especificado. Na Figura 17 é apresentado um 
exemplo dos objetos metadados que foram salvos no repositório do schema “HR”. 
Figura 17: Listando objetos metadados no Repositório. 
 
Fonte: o próprio autor. 
 
 
Página 47 
 
Nessa tela são ilustrados cinco registros à esquerda. Nela está contido objeto 
metadado “PRC_TESE_REPO”, do tipo procedure que foi criado no schema “HR”. 
Foram realizados cinco modificações nesse objeto em tempos distintos, e a medida que 
o repositório foi executado, ele identificou a ultima modificação feita desse objeto e 
armazenou no repositório. Na coluna descrita como “ALTERADO” pode ser observado 
a data e hora de quando foram realizadas as modificações desse objeto metadados, e a 
direita da tela pode-se consultar o código gerado desse objeto metadado selecionado e 
comparar com as modificações feitas anteriormente. 
 
 
Página 48 
 
 CAPÍTULO 4 
CONSIDERAÇÕES FINAIS 
______________________________________ 
Este trabalho teve como objetivo descrever os principais objetos metadados em 
banco de dados relacional. Neste caso foi apresentado e estudado o SGDB Oracle bem 
como suas ferramentas de backup e restauração para prevenir a perda dos objetos 
metadados. 
Para utilizar outros SGBDs para implementar esse mesmo repositório, o banco 
deve possuir todos os tipos de objetos que foram citados desde o inicio e também as 
configurações similares ao Oracle como o caso do dicionário de dados que utilizamos 
para identificar os objetos metadados modificados. 
Tendo como base a análise dos resultados, foi possível identificar que para 
realizar as tarefas de administração de banco de dados é preciso ter um conhecimento 
necessário, sendo geralmente feito por um administrador de banco de dados. Deve-se 
ainda levar em conta que talvez no estudo de outros SGDBS, poderiam ter sido 
identificadas ferramentas com menos complexidade de uso. 
Também podemos dizer que muitos desenvolvedores não têm o mesmo 
conhecimento e privilégios para realizar as tarefas de administração de banco, e na 
maioria das vezes pode acontecer de precisar restaurar algum objeto com problema ou 
perdido. 
Por fim, pode-se concluir que para facilitar a recuperação dos objetos metadados 
no banco de dados Oracle, a solução apresentada para criar um repositório de objetos 
metadados integrada com uma interface gráfica, facilita o seu uso na recuperação e 
consultas dos objetos criados ou modificados pelo desenvolvedor, além de manter um 
 
 
Página 49 
 
nível de segurança maior por estar salvo no próprio banco e não diretamente no sistema 
operacional. 
4.1 Trabalhos Futuros 
Com base no trabalho desenvolvido, a seguir são apresentados alguns trabalhos 
que podem ser desenvolvidos considerando a evolução do repositório: 
 Implementar auditoria de usuário por sessão e envio de e-mail possibilitando o 
envio de notificações quando um objeto for alterado ou enviar outras 
notificações de alteração do repositório. 
 Identificar outras possíveis melhorias para o repositório e interface gráfica, 
levando em conta que existe outas ferramentas similares como, por exemplo, a 
ferramenta FlyWay desenvolvida pela Boxfuse. 
 Identificar em outras tecnologias de SGBDS a possibilidade de implementar o 
mesmo repositório. 
Buscar um tratamento para as chaves de objetos do tipo tabela que possuem 
dependências com outros objetos do tipo, de maneira que o repositório consiga lidar 
com as mudanças de versões buscando essas dependências. 
4.2 Resultados e Discussões 
O desenvolvimento do repositório e da interface gráfica foi concluído com 
sucesso, atingindo-se assim a meta proposta para este trabalho. Alguns itens que valem 
a pena serem destacados sobre o Repositório são: 
 Segurança: Os objetos ficaram salvos com segurança em nível de banco de 
dados não podendo ser excluídos fisicamente. 
 Agilidade: A possibilidade de restaurar um objeto metadado em pouco tempo 
em relação a outros tipos de backups. 
 
 
Página 50 
 
 Histórico: Saber o que foi alterado através de histórico de tempo de cada objeto 
metadados. 
 Custo/Beneficio: Ter uma ferramenta livre e de fácil uso em relação a outras 
semelhantes. 
A interface gráfica foi desenvolvida com o intuito de facilitar o uso do repositóriono banco de dados, mas ele pode ser manuseado através de comandos SQL pelo próprio 
banco de dados. Em um modo geral, o repositório foi desenvolvido para ajudar nas 
tarefas do dia a dia dos desenvolvedores, podendo através desse repositório salvar seus 
objetos metadados criados no banco e recuperá-los quando ocorrer algum problema de 
perda ou erro no código do objeto sem a necessidade da ajuda de um DBA. 
 
 
Página 51 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
______________________________________ 
BLUMM, Cesar. Banco de dados gratuitos, SQL Magazine, Ed. 31. Disponível Em: 
http://www.devmedia.com.br/artigo-sql-magazine-31-bancos-de-dados-gratuitos-
conheca-as-novas-opcoees-da-oracle-e-microsoft/6760. Acesso em: 27 fev. 2015. 
 
COUTO, Eder. Reduzindo o tempo de recuperação de incidentes através do Oracle 
Flashback – Revista SQL Magazine, Ed. 62. Disponível Em: 
http://www.devmedia.com.br/reduzindo-o-tempo-de-recuperacao-de-incidentes-atraves-
do-oracle-flashback/11882. Acesso em: 25 fev. 2015. 
 
DATE, C.J. Introdução a sistemas de banco de dados. Rio de Janeiro: Campus, 
2004. Tradução de: An introduction to Database system – 8 .ed. americana. 
 
GAJIK, Zarko. 2011. Delphi History: the Roots. 2008 Disponível em: 
http://delphi.about.com/cs/azindex/a/dhistory.htm. Acesso em: 25 fev. 2015. 
 
GRACIA-MOLINA, Hector. ULLMAN, Jeffery D. WIDOM, Jennifer. Implementação 
de sistemas de banco de dados. Rio de Janeiro: Campus 2001. Tradução de: Database 
system implementation. 
 
PRADO, Fábio. Repositório de metadados - Blog do DBA, 2012. Disponível em: 
http://www.fabioprado.net/2012/06/repositorio-de-metadados-no-oracle.html. Acesso 
em: 25 out. 2014. 
 
PRADO, Fábio. Versionamento de objetos de banco de dados - Revista SQL 
Magazine, 2012. Ed. 107. Disponível em: http://www.devmedia.com.br/revista-sql-
magazine-107/26884. Acesso em: 26 out. 2014. 
 
SPINOLA, Rodrigo. Objetos no banco de dados – Revista SQL Magazine, 2012. Ed. 
90. Disponível em: http://www.devmedia.com.br/revista-sql-magazine-90/21999. 
Acesso em: 08 nov. 2014. 
 
ORACLE, Database. Backup and Recovery User’s Guide 12c Relese (12.1), 2014. Ed. 
E50658-06. Disponível em: https://docs.oracle.com/database/121/BRADV/E50658-
06.pdf. Acesso em: 22 fev. 2015. 
 
OLIVEIRA, Wilson José de. Oracle 8i & PL-SQL. Visual Books, 2000. 
 
http://www.devmedia.com.br/artigo-sql-magazine-31-bancos-de-dados-gratuitos-conheca-as-novas-opcoees-da-oracle-e-microsoft/6760
http://www.devmedia.com.br/artigo-sql-magazine-31-bancos-de-dados-gratuitos-conheca-as-novas-opcoees-da-oracle-e-microsoft/6760
http://www.devmedia.com.br/reduzindo-o-tempo-de-recuperacao-de-incidentes-atraves-do-oracle-flashback/11882
http://www.devmedia.com.br/reduzindo-o-tempo-de-recuperacao-de-incidentes-atraves-do-oracle-flashback/11882
http://delphi.about.com/cs/azindex/a/dhistory.htm
http://www.fabioprado.net/2012/06/repositorio-de-metadados-no-oracle.html
http://www.devmedia.com.br/revista-sql-magazine-107/26884
http://www.devmedia.com.br/revista-sql-magazine-107/26884
http://www.devmedia.com.br/revista-sql-magazine-90/21999
https://docs.oracle.com/database/121/BRADV/E50658-06.pdf
https://docs.oracle.com/database/121/BRADV/E50658-06.pdf
 
 
Página 52 
 
REZENDE, Ricardo. Conceitos Fundamentais de Banco de Dados. Disponível em: 
http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649. Acesso 
em: 24 nov. 2014. 
 
SELLA, Bruno. Projeto de banco de dados. Faculdade de Tecnologia da Zona 
Leste, São Paulo, 2010. Disponível em: http://fateczl.edu.br/TCC/2010-2/TCC-
001.pdf. Acesso em: 25 nov. 2014 
 
http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649
http://fateczl.edu.br/TCC/2010-2/TCC-001.pdf
http://fateczl.edu.br/TCC/2010-2/TCC-001.pdf
 
 
Página 53 
 
APÊNCICE A – CÓDIGO FONTE DO 
REPOSITÓRIO 
______________________________________ 
 Na tabela 11 é apresentado o código fonte utilizado para criação do repositório 
no banco e dados. 
Tabela 11: Código Fonte do Repositório. 
Descrição Código Fonte 
Criação do Schema de 
banco e atribuição dos 
privilégios. 
CREATE USER USR_REPO IDENTIFIED BY "123456"; 
ALTER USER USR_REPO QUOTA UNLIMITED ON USERS; 
GRANT CONNECT, 
 CREATE ANY TABLE, 
 CREATE ANY INDEX, 
 ALTER ANY INDEX, 
 DROP ANY INDEX, 
 CREATE ANY JOB, 
 DEBUG ANY PROCEDURE, 
 CREATE ANY PROCEDURE, 
 EXECUTE ANY PROCEDURE, 
 CREATE SEQUENCE, 
 CREATE TRIGGER, 
 SELECT ANY DICTIONARY, 
 SELECT_CATALOG_ROLE 
 TO USR_REPO; 
Criação das tabelas, 
sequence e trigger 
CREATE TABLE CONFIGURA_JOB_REPO 
( 
 DTA_INICIO DATE NOT NULL, 
 SEMANA VARCHAR2(30) NOT NULL, 
 FREQUENCIA VARCHAR2(30) NOT NULL, 
 INTERVALO CHAR(2) NOT NULL, 
 HORA CHAR(2) NOT NULL, 
 MINUTO CHAR(2) NOT NULL 
); 
 
CREATE TABLE USR_REPO.USUARIOS_REPO( 
COD_USUARIO NUMERIC PRIMARY KEY, 
NOME_USUARIO VARCHAR(30 BYTE) NOT NULL ENABLE 
); 
INSERT INTO CONFIGURA_JOB_REPO VALUES(SYSDATE,'SUN','DELAY',0,'00','00'); 
COMMIT; 
 
CREATE SEQUENCE SEQ_USUARIO_REPO 
 START WITH 1 
 INCREMENT BY 1 
 NOCACHE 
 NOCYCLE; 
 
CREATE OR REPLACE TRIGGER TEG_USUARIO_REPO 
 BEFORE INSERT ON USUARIOS_REPO 
 FOR EACH ROW 
DECLARE 
BEGIN 
 SELECT SEQ_USUARIO_REPO.NEXTVAL INTO :NEW.COD_USUARIO FROM 
DUAL; 
END; 
/ 
 
 
 
Página 54 
 
CREATE TABLE USR_REPO.OBJETO_REPO( 
COD_OBJETO NUMERIC PRIMARY KEY, 
TIPO_OBJETO VARCHAR2(30 BYTE) NOT NULL ENABLE, 
COD_USUARIO NUMERIC NOT NULL, 
CONSTRAINT FK_COD_USUARIO FOREIGN KEY (COD_USUARIO) REFERENCES 
USUARIOS_REPO(COD_USUARIO) 
); 
 
 
CREATE SEQUENCE SEQ_OBJETO_REPO 
 START WITH 1 
 INCREMENT BY 1 
 NOCACHE 
 NOCYCLE; 
 
CREATE OR REPLACE TRIGGER TEG_OBJETO_REPO 
 BEFORE INSERT ON OBJETO_REPO 
 FOR EACH ROW 
DECLARE 
BEGIN 
 SELECT SEQ_OBJETO_REPO.NEXTVAL INTO :NEW.COD_OBJETO FROM DUAL; 
END; 
/ 
 
CREATE TABLE USR_REPO.REPOSITORY_METADATA 
( 
TX_OBJECT_DDL CLOB, 
NM_SCHEMA VARCHAR2(30 BYTE) NOT NULL ENABLE, 
NM_OBJECT VARCHAR2(30 BYTE) NOT NULL ENABLE, 
DT_LAST_UPDATE DATE NOT NULL ENABLE, 
DS_OBJECT_TYPE VARCHAR2(19 BYTE) NOT NULL ENABLE, 
DT_INSERT_REG DATE NOT NULL ENABLE, 
CONSTRAINT PK_REPOSITORYMETADATA PRIMARY KEY 
(NM_SCHEMA, NM_OBJECT, DS_OBJECT_TYPE, DT_LAST_UPDATE) 
); 
Criação do 
procedimento. 
CREATE OR REPLACE PROCEDURE PRC_REPOSITORIO_METADADOS 
AUTHID CURRENT_USER AS 
 S_DDL CLOB; 
 EXISTE INTEGER; 
BEGIN 
 FOR I IN (SELECT X.* 
 FROM (SELECT DISTINCT U.USERNAME SCHEMA, O.NAME NAME, 
 DECODE(O.TYPE#, --0, 'NEXT_OBJECT',1,'INDEX',2,'TABLE',--3, 
'CLUSTER',4,'VIEW',--5, 'SYNONYM',--6, 
'SEQUENCE',7,'PROCEDURE',8,'FUNCTION',9,'PACKAGE',11,'PACKAGE_BODY',12,'TR
IGGER',--13, 'TYPE',--14, 'TYPE_BODY',--19, 'TABLE_PARTITION',--20, 
'INDEX_PARTITION',--21, 'LOB',--22, 'LIBRARY',--23, 'DIRECTORY',--24, 'QUEUE',--28, 
'JAVA_SOURCE',--29, 'JAVA_CLASS',--30, 'JAVA_RESOURCE',--32, 'INDEXTYPE',--33, 
'OPERATOR',--34, 'TABLE_SUBPARTITION',--35, 'INDEX_SUBPARTITION',--40, 
'LOB_PARTITION',--41, 'LOB_SUBPARTITION',42,'MATERIALIZED_VIEW',--43, 
'DIMENSION',--44, 'CONTEXT',--46, 'RULE_SET',--47, 'RESOURCE_PLAN',--48, 
'CONSUMER_GROUP',--51, 'SUBSCRIPTION',--52, 'LOCATION',--55, 'XMLSCHEMA',--
56, 'JAVA_DATA',--57, 'SECURITY_PROFILE',--59, 'RULE',--62, 
'EVALUATION_CONTEXT',66,'PROCOBJ','UNDEFINED') TYPE, O.MTIME L_DATE 
 FROM SYS.OBJ$ O 
 INNER JOIN SYS.ALL_USERS U 
 ON (O.OWNER# = U.USER_ID) 
 INNER JOIN SYS.DBA_OBJECTS DO 
 ON (O.NAME = DO.OBJECT_NAME AND U.USERNAME = DO.OWNER) 
 WHERE O.TYPE# IN (1, 2, 4, 7, 8, 9, 11, 12, 42, 66) 
 AND U.USERNAME NOT IN 
('USR_REPO','RMAN','ORACLE','ROOT','MGMT_VIEW','SYSMAN','OPS$ORACLE','APE
X_PUBLIC_USER','ORACLE_OCM','TSMSYS','DBSNMP','CTXSYS','ANONYMOUS','DMSYS','WKSYS','WK_TEST,WKPROXY','OLAPSYS','FLOWS_FILES','APEX_030200','MDS
YS','WMSYS','SI_INFORMTN_SCHEMA','ORDSYS, 
EXFSYS','XDB','ORDPLUGINS','OUTLN','SYS','SYSTEM','APPQOSSYS','EXFSYS','ORD
 
 
Página 55 
 
DATA','ORDSYS','D4OSYS','APEX_040100') 
 AND DO.GENERATED = 'N' 
 MINUS 
 SELECT MO.NM_SCHEMA SCHEMA, 
 MO.NM_OBJECT NAME, 
 MO.DS_OBJECT_TYPE, 
 MAX(MO.DT_LAST_UPDATE) L_DATE 
 FROM REPOSITORY_METADATA MO 
 GROUP BY MO.NM_SCHEMA, MO.NM_OBJECT, MO.DS_OBJECT_TYPE) 
X 
 WHERE X.SCHEMA IN (SELECT NOME_USUARIO FROM USUARIOS_REPO) 
 AND X.TYPE IN (SELECT TIPO_OBJETO FROM OBJETO_REPO)) LOOP 
 EXISTE := 0; 
 IF I.TYPE = 'PROCOBJ' THEN 
 SELECT COUNT(*) 
 INTO EXISTE 
 FROM REPOSITORY_METADATA 
 WHERE NM_OBJECT = I.NAME 
 AND NM_SCHEMA = I.SCHEMA; 
 END IF; 
 IF EXISTE = 0 THEN 
 SELECT DBMS_METADATA.GET_DDL(I.TYPE, I.NAME, I.SCHEMA) 
 INTO S_DDL 
 FROM DUAL; 
 INSERT INTO REPOSITORY_METADATA 
 (TX_OBJECT_DDL, 
 NM_SCHEMA, 
 NM_OBJECT, 
 DT_LAST_UPDATE, 
 DS_OBJECT_TYPE, 
 DT_INSERT_REG) 
 VALUES 
 (S_DDL, I.SCHEMA, I.NAME, I.L_DATE, I.TYPE, SYSDATE); 
 END IF; 
 END LOOP; 
 COMMIT; 
END; 
/ 
Criação da job que 
executa o repositório. 
BEGIN 
 DBMS_SCHEDULER.CREATE_JOB ( 
 JOB_NAME => 'JOB_REPO', 
 JOB_TYPE => 'PLSQL_BLOCK', 
 JOB_ACTION => 'BEGIN USR_REPO.PRC_REPOSITORIO_METADADOS; END;', 
 START_DATE => SYSTIMESTAMP, 
 REPEAT_INTERVAL => 'FREQ=HOURLY; BYMINUTE=0; BYSECOND=0;', 
 END_DATE => NULL, 
 ENABLED => TRUE, 
 COMMENTS => 'JOB DEFINED ENTIRELY BY THE CREATE JOB 
PROCEDURE.'); 
END; 
/