modelo de tcc para o curso de ciência da ... - univalisiaibib01.univali.br/pdf/daniel paiva...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ESTUDO COMPARATIVO ENTRE BANCO DE DADOS RELACIONAL
E XML NATIVO
Área de Banco de Dados
por
Daniel Paiva Filho
Alexandre Biazin, M. Sc
Itajaí (SC), junho de 2010
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ESTUDO COMPARATIVO ENTRE BANCO DE DADOS RELACIONAL
E XML NATIVO
Área de Banco de Dados
por
Daniel Paiva Filho
Relatório apresentado à Banca
Examinadora do Trabalho de Conclusão do
Curso de Ciência da Computação para
análise e aprovação.
Orientador: Alexandre Biazin, M. Sc
Itajaí (SC), junho de 2010
ii
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................. iv
LISTA DE FIGURAS ................................................................................. v
LISTA DE TABELAS .............................................................................. vi
RESUMO .................................................................................................. vii
ABSTRACT ............................................................................................. viii
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO ...................................................................... 2
1.1.1 Formulação do Problema ................................................................................. 2
1.1.2 Solução Proposta ............................................................................................... 3
1.2 OBJETIVOS ......................................................................................... 3
1.2.1 Objetivo Geral ................................................................................................... 3
1.2.2 Objetivos Específicos ........................................................................................ 4
1.3 METODOLOGIA ................................................................................ 4
1.4 ESTRUTURA DO TRABALHO ........................................................ 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 6
2.1 LINGUAGEM XML ............................................................................ 6
2.1.1 Surgimento da linguagem XML ...................................................................... 8
2.1.2 Definição de tipo de documento (DTD) .......................................................... 9
2.1.3 Esquema XML ................................................................................................ 11
2.1.4 Corpo do documento....................................................................................... 13
2.1.5 Razões para utilizar XML .............................................................................. 18
2.2 FORMAS DE ARMAZENAMENTO DE DADOS XML .............. 20
2.3 BANCO DE DADOS .......................................................................... 21
2.3.1 Banco de dados relacionais com suporte XML ............................................ 24
2.3.1.1 Armazenamento com granulação pequena................................................. 26
2.3.1.2 Armazenamento com granulação grande ................................................... 29
2.3.2 Banco de dados XML Nativo ......................................................................... 29
2.4 FERRAMENTAS DE DESENVOLVIMENTO ............................. 31
2.4.1 Bancos de dados Oracle .................................................................................. 31
2.4.2 Linguagem de Programação .......................................................................... 33
2.5 SOLUÇÕES SIMILARES................................................................. 34
3 DESENVOLVIMENTO ...................................................................... 36
3.1 PROTÓTIPO DE ARMAZENAMENTO DE
DOCUMENTOS XML ............................................................................. 37
3.1.1 Arquitetura ...................................................................................................... 41
iii
3.1.2 Banco de Dados XML Nativo ........................................................................ 42
3.2 ANÁLISE DE REQUISITOS ........................................................... 46
3.2.1 Requisitos Funcionais ..................................................................................... 47
3.2.2 Requisitos Não Funcionais ............................................................................. 47
3.2.3 Regras de negócio ............................................................................................ 47
3.3 DIAGRAMAS DE CASOS DE USO ................................................ 48
3.4 DIAGRAMA DE CLASSES ............................................................. 48
3.5 TELAS DO PROTÓTIPO ................................................................. 49
3.5.1 Carregar Documentos XML .......................................................................... 50
3.5.2 Consultar Documentos XML ......................................................................... 51
3.5.3 Remover Documentos XML .......................................................................... 52
3.5.4 Gerar Relatório ............................................................................................... 53
3.5.5 Limpa Tabelas ................................................................................................. 53
3.6 DIAGRAMAS DE SEQUÊNCIA ..................................................... 54
3.6.1 Gravação de Documentos ............................................................................... 54
3.6.2 Consulta de Documentos ................................................................................ 55
3.7 DIAGRAMAS ER .............................................................................. 56
3.8 ANÁLISE DOS RESULTADOS....................................................... 57
3.8.1 Armazenamento, Recuperação e Remoção de dados XML ........................ 57
3.8.2 Complexidade de Implementação e Manutenção ........................................ 59
4 CONCLUSÃO .................................................................................... 61
4.1 ANÁLISE DOS RESULTADOS....................................................... 62
5 REFERÊNCIAS BIBLIOGRÁFICAS ............................................... 64
iv
LISTA DE ABREVIATURAS
AJAX Asynchronous JavaScript and XML
API Application Programming Interfaces
B2B Business-to-Business
CSS Cascading Style Sheet
DBA Database Administrator
DTD Document Type Definition
DOM Document Object Model
ER Entidade-Relacionamento
GML Generalized Markup Language
HTML Hyper Text Markup Language
ISO International Organization for Standardization
ODF Open Document Format
PDF Portable Document Format
RSS Really Simple Syndication
SAX Simple API for XML
SGBD Sistema Gerenciador de Banco de Dados
SGBDOO Sistema Gerenciador de Banco de Dados Orientado a Objeto
SGBDOR Sistema Gerenciador de Banco de Dados Objeto Relacional
SGML Standard Generalized Markup Language
TCC Trabalho de Conclusão de Curso
UML Unified Modeling language
UNIVALI Universidade do Vale do Itajaí
URI Uniform Resource Identifiers
XSDL Linguagem de definição do Esquema XML
XSLT Extensible Stylesheet Language Transformation
XML eXtensible Markup Language
W3C WWW Consortium
v
LISTA DE FIGURAS
Figura 1. Exemplo XML ............................................................................................................ 7
Figura 2. Exemplo documento XML com DTD interno .......................................................... 10 Figura 3. Exemplo XML Schema ............................................................................................. 11 Figura 4. Documento XML ...................................................................................................... 12 Figura 5. NAMESPACES ........................................................................................................ 16 Figura 6. XPOINTER ............................................................................................................... 18
Figura 7. Os três níveis de abstração dos dados ....................................................................... 23 Figura 8. Esquema lógico no modelo de dados relacional usando a granulação pequena ....... 26
Figura 9. Esquema Lógico normalizado ................................................................................... 27 Figura 10. Esquema Lógico normalizado do banco relacional com granulação pequena para
armazenamento XML ....................................................................................................... 28 Figura 11 - Diagrama de atividades para Gravação do Documento ......................................... 38 Figura 12 - Diagrama de Atividade para Consulta de Documentos ......................................... 39
Figura 13 - API DOM ............................................................................................................... 41 Figura 14 - Método para criar conexão .................................................................................... 42 Figura 15 - Interface Web Oracle 10g ...................................................................................... 42 Figura 16 - Criação de tabelas .................................................................................................. 43
Figura 17 - Criar tabela XMLTABLE ...................................................................................... 44 Figura 18 - Inserção de Dados .................................................................................................. 44
Figura 19 - Função insereXML().............................................................................................. 45 Figura 20 - Função getClob() ................................................................................................... 46
Figura 21. Diagrama de Casos de Uso ..................................................................................... 48 Figura 22 - Diagrama de Classe ............................................................................................... 49
Figura 23. Tela de Controle ...................................................................................................... 50 Figura 24. Tela de Gravação no Banco .................................................................................... 50 Figura 25. Tela de consulta ao banco ....................................................................................... 51
Figura 26 - Consulta por Cliente .............................................................................................. 52 Figura 27 - Tela Remoção ........................................................................................................ 52 Figura 28 - Relatório de Tempos .............................................................................................. 53
Figura 29 - Diagrama de Sequência - Gravação ....................................................................... 54 Figura 30 - Diagrama de Sequência - Consulta ........................................................................ 55
Figura 31 - MER Relacional ..................................................................................................... 56 Figura 32 - MER Nativo ........................................................................................................... 57
vi
LISTA DE TABELAS
Tabela 1. Especificação do Objeto ........................................................................................... 12
Tabela 2. Mapeamento do documento XML para campos do objeto ....................................... 13 Tabela 3. Especificação do Objeto ........................................................................................... 13 Tabela 4. Exemplo de instância da relação da tabela cidade .................................................... 25 Tabela 5. Funções do tipo de dados XMLTYPE ...................................................................... 33 Tabela 6 - Armazenamento....................................................................................................... 58
Tabela 7 - Consulta por Documento ......................................................................................... 58 Tabela 8 - Consulta por Clientes .............................................................................................. 59
Tabela 9 – Remoção ................................................................................................................. 59 Tabela 10 - Tabela NFE............................................................................................................ 70 Tabela 11 - Tabela ITENS ........................................................................................................ 72 Tabela 12 - Tabela SIGNATURE ............................................................................................ 73 Tabela 13 - Tabela XMLTYPE ................................................................................................ 73
vii
RESUMO
PAIVA FILHO, Daniel. Estudo comparativo entre banco de dados relacional e XML
nativo. Itajaí, 2010. 80. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do
Itajaí, 2010.
Com o aumento da utilização de dados XML, por ser uma linguagem de marcação de fácil
entendimento e um formato de arquivo flexível para as trocas de dados entre sistemas,
empresas desenvolvedoras de software estão buscando uma solução mais eficiente para esse
armazenamento. Assim sendo, surgiram os bancos de dados com suporte XML e os bancos de
dados que armazenam esses documentos na sua forma nativa. Com a finalidade de avaliar o
armazenamento de XML, foi construído um protótipo capaz de armazenar documentos XML
nos dois modelos de banco de dados. Para a construção desse protótipo foi utilizada a
linguagem JAVA e foram modeladas duas bases distintas no banco de dados, uma que
armazena esse formato de forma relacional e outra que armazena os dados de maneira nativa.
Os resultados obtidos desses testes foram comparados, bem como as fases de
desenvolvimento de todo o processo, para que fossem definidas as diferenças, vantagens e
desvantagens de cada modelo.
Palavras-chave: XML. Banco de Dados. Banco de Dados XML.
viii
ABSTRACT
PAIVA FILHO, Daniel. Comparative study of relational database and xml native. Itajaí,
2010. 80. Completion of course work (Bachelor's Degree in Computer Science), Science
Technology Center of the Earth and Sea, University of Vale do Itajaí, 2010.
With the increasing use of XML data, because it is a markup language for easy understanding
and a flexible file format for exchanging data between systems, software development
companies are seeking a more efficient solution to that store. Thus arose the databases with
XML support and the databases that store these documents in their native form. In order to
evaluate the storage of XML, we built a prototype to store XML documents in both models of
the database. To build this prototype was used JAVA language and were modeled two
different bases in the database, one that stores the format of a relational form and another
that stores data natively. The results of these tests were compared, as well as the development
phases of the process in order to be defined the differences, advantages and disadvantages of
each model.
Keywords:XML.Database.XML.Database.
1 INTRODUÇÃO
As empresas buscam responder cada vez mais rapidamente aos seus clientes, parceiros
e fornecedores. Para isso, há um grande esforço na área de integração de sistemas e uma
constante busca por trocas de dados mais eficientes entre as organizações, conforme explicam
Deitel et. al. (2003).
Para Quin (2009) uma das soluções encontradas foi o uso do XML (Extensible
Markup Language) para troca de dados entre aplicações. XML é uma metalinguagem, ou seja,
uma linguagem usada para descrever outras linguagens, caracterizada por ser simples e
flexível. Tem a finalidade de descrever os dados em uma estrutura hierárquica. Foi
originalmente concebida para responder aos desafios da publicação eletrônica em larga escala,
porém está ganhando muita importância na troca de dados.
A utilização de documentos XML é comentada por Chang et. al. (2001), ao destacar
que esta é fácil de ler e compreender porque suas tags são associadas aos dados, por exemplo,
<autor first name>Juan</author first name>.
Conforme explica Quin (2009) um desafio que surgiu com a utilização do XML foi
armazenar a grande quantidade de dados que estava trafegando nas aplicações. Os
especialistas das empresas perceberam que a utilização desse formato estava causando efeitos
adversos que afetam o desempenho da aplicação, tornando sua administração extremamente
cara. Com isso as grandes empresas desenvolvedoras de software passaram a construir banco
de dados que possuem suporte a armazenamento XML.
Banco de dados na visão de Ramakrishnan (2008, p.03) pode ser conceituado como:
“[...] uma coleção de dados que, tipicamente, descreve as atividades de uma ou mais
organizações relacionadas”. Os dados armazenados em um banco de dados possuem a
propriedade de persistir e serem manipulados o que é feito através de um software, chamado
de sistema de gerenciamento de banco de dados (SGBD).
Banco de Dados XML, como explicado por Graves (2003, p.10) é definido como
“conjunto de documentos orientados ao processamento de dados e que possuem operações
mais voltadas à manipulação de dados do que ao processamento de texto”.
O autor explica ainda que um repositório de dados XML, pode ser utilizado como
elemento central na transferência de dados, principalmente quando as aplicações ou usuários
estiverem em empresas diferentes.
2
Ainda na visão do autor, dados XML armazenados permitem pesquisas ou interações
com outros aplicativos, como sistemas de auditoria. Também podem atender outras
necessidades como reter informações importantes em um sistema seguro, ou capturar
informações que sejam representadas de forma mais clara usando esta linguagem.
Outra vantagem em utilizar o BD com suporte XML destacada por Graves (2003) é o
custo de memória e processamento, pois carregar grandes árvores de documentos XML
exigiria muita memória e um banco XML pode facilmente armazenar esses dados. Também
pode ser utilizado para inserir o dado diretamente na base de dados sem a necessidade de
manipulação dos documentos, respeitando a hierarquia e preservando a estrutura deste.
O enfoque desse trabalho foi um estudo comparativo sobre armazenamento de
documentos XML em dois diferentes modelos de banco de dados: relacional e nativo. Esses
conceitos foram aplicados em um protótipo capaz de manipular documentos XML,
possibilitando a gravação, consulta e remoção nos dois modelos de banco.
Esse protótipo possibilita ainda a geração de relatórios com tempos utilizados na
manipulação dos documentos nos dois modelos de banco para comparar aspectos positivos e
negativos, e avaliar a melhor performance e complexidade de desenvolvimento.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O problema de pesquisa permite estabelecer o foco do estudo e apresentar os motivos
da sua realização, como enfatiza Gil (2002, p. 24) “um problema é de natureza científica
quando envolve variáveis que podem ser tidas como testáveis”, e complementando, Mattar
(2005, p.62) ressalta que “o primeiro passo para formulação do problema é torná-lo concreto e
explícito”.
Atualmente existe um amplo conjunto de tecnologias que permitem de forma mais ou
menos complexa, a troca de dados e informação entre sistemas. A crescente utilização de
redes de equipamentos, onde o poder computacional encontra-se distribuído por diversas
máquinas, tem permitido maximizar a troca de informação e contribuído para o surgimento de
novos negócios eletrônicos.
Com o crescimento da troca de dados entre aplicações, as empresas passaram a utilizar
documentos XML. Com isso surge a necessidade de armazená-los em um ambiente que
3
forneça recursos de banco de dados. Sendo assim, as empresas desenvolvedoras de banco de
dados passaram a oferecer suporte a dados XML.
O tema desse trabalho é um estudo comparativo entre banco de dados XML nativo e
relacional com suporte a XML, onde foram comparadas as fases de projeto de banco de
dados, as formas de armazenamento de cada banco de dados e suas operações. Esses critérios
de comparação buscam mensurar o que melhor se adéquam os modelos, podendo assim dizer
quais seus pontos fortes e fracos.
1.1.2 Solução Proposta
As soluções e tecnologias apresentam frequentes mudanças, sendo assim as empresas
enfrentam dificuldades em encontrar a melhor solução para seus problemas relacionados a
sistemas.
A proposta deste trabalho é desenvolver um protótipo capaz de armazenar XML em
duas bases de dados, uma aceitando dados de forma nativa utilizando o tipo de dados
chamado XMLTYPE e outra armazenando dados de forma relacional, ambas utilizando o
banco de dados Oracle. Por meio do protótipo, é possível realizar um estudo comparativo
sobre as principais características de cada modelo.
Com esse estudo é possível determinar as aplicações mais adequadas para cada forma
de armazenamento e com a utilização dos resultados buscar o modelo que apresenta maior
eficiência e melhor comportamento.
Considerando a tendência de crescimento deste tipo de tecnologia, esta proposta é
interessante como TCC (Trabalho de Conclusão de Curso) podendo servir como referência de
estudos para tecnologias de implementação de aplicações que utilizem XML para troca de
dados e necessitem de um repositório de dados no formato XML.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral é efetuar um estudo comparativo entre as formas de armazenamento
de documentos XML no formato relacional e também no formato de XML nativo, para que
sejam mensurados os benefícios ao se utilizar cada modelo de armazenamento.
4
1.2.2 Objetivos Específicos
Com a finalidade de atender o objetivo geral, foram definidos os seguintes objetivos
específicos:
Estudar conceitos e vantagens dos bancos de dados XML;
Verificar as tecnologias necessárias para o desenvolvimento do trabalho;
Determinar os requisitos do protótipo;
Desenvolvimento do projeto do protótipo;
Implementar protótipo;
Validar a solução de BD XML como repositório;
Fazer comparativo entre banco de dados relacionais e de suporte XML nativo;
Documentar o sistema e os resultados obtidos; e
Analisar desempenho, aplicabilidade e funcionalidade.
1.3 METODOLOGIA
Como observa Richardson (1999, p.22), “a metodologia são os procedimentos e regras
utilizadas por determinado método. A metodologia são as regras estabelecidas para o método
científico [...]”.
Complementando, Roesch (2005), afirma que o uso de métodos e técnicas torna o
trabalho mais completo, guiando o pesquisador de forma a analisar melhor a variedade de
situações e problemas encontrados ao longo do estudo.
Para realizar esse trabalho de pesquisa serão necessárias cinco etapas: (1) estudo, (2)
modelagem, (3) desenvolvimento, (4) validação e (5) documentação. As etapas 1 e 2 foram
realizadas no TCC I, enquanto as etapas 3, 4 e 5 realizadas no TCC II.
A primeira etapa é a pesquisa por conceitos e vantagens dos bancos de dados XML,
onde houve busca por literatura e artigos científicos na área com a finalidade de conhecer
melhor as vantagens de se utilizar banco de dados com XML. Posteriormente, foi realizado
levantamento de conceitos como XML e banco de dados para tratar como base para o
trabalho.
O passo seguinte foi buscar ferramentas com suporte XML necessárias a
implementação do sistema. Estudo da ferramenta divide-se em: instalação do servidor de
5
banco de dados Oracle versão 10g e criação das bases de dados com a finalidade de testar a
ferramenta com ênfase no XML. O estudo deve focar a manipulação e inserção de dados no
formato XML.
Na segunda etapa, foi feita a modelagem da aplicação através da UML (Unified
Modeling Language – Modelagem – Linguagem de Modelagem Unificada) para a modelagem
funcional do sistema, onde foram coletados os requisitos para o desenvolvimento do
protótipo.
Nas etapas seguintes, foram realizados o desenvolvimento e a implementação do
protótipo, onde o trabalho foi avaliado e documentado para que fosse possível obter as
considerações finais a respeito da solução de Banco de Dados XML como repositório.
1.4 ESTRUTURA DO TRABALHO
Este trabalho está divido em capítulos: Introdução, Fundamentação Teórica,
Desenvolvimento e Conclusão. A Introdução apresenta uma visão geral do trabalho, a
motivação da realização da pesquisa, os objetivos gerais e específicos, a metodologia e a
estrutura do trabalho.
Na Fundamentação Teórica são descritos todos os conceitos necessários para a
elaboração do desenvolvimento. Nesse capítulo são definidos os principais recursos de cada
banco de dados, bem como suas diferenças e características.
No Capítulo do Desenvolvimento é explicado como foi desenvolvido o protótipo e as
suas principais características. Também apresenta a análise efetuada dos resultados obtidos.
O último capítulo aborda Considerações Finais, onde são apresentados os tópicos
relativos às conclusões finais e também sugestões de trabalhos futuros.
6
2 FUNDAMENTAÇÃO TEÓRICA
Na fundamentação teórica busca-se esclarecer os conceitos, requisitos e tecnologias
necessárias para a realização do estudo comparativo entre as formas de armazenamento de
XML em banco de dados.
Para isso, foram selecionados como temas principais da fundamentação os assuntos:
XML, Bancos de Dados, Banco de Dados XML, e banco de dados relacionais com suporte
XML.
No primeiro tema são explicados conceitos e vantagens do uso de XML revisando
conceitos da linguagem, surgimento, benefícios, principais características e as vantagens e
desvantagens da utilização de XML nos sistemas. Tópicos sobre padrões XML como
definição de tipos de documentos, esquemas XML, e APIs de programação também serão
apresentados.
Em seguida, são abordados tópicos de bancos de dados, apresentando conceitos e
características, bem como diferentes tipos de modelagem de um documento XML tratando
suas vantagens e desvantagens.
Na sequência bancos de dados relacionais e os bancos de dados XML serão
conceituados levando em consideração as características de cada modelo, vantagens e
desvantagens, classificando as situações nas quais cada modelo melhor se adapta.
2.1 LINGUAGEM XML
Zmoginski (2008) explica que XML foi considerado oficialmente como extensão
padrão em documentos eletrônicos pela ISO (Internation Organization Standartization). Essa
notícia comprova como XML vem ganhando espaço nas empresas de tecnologias e nas
aplicações desenvolvidas. Com essa aprovação, XML ganha mesmo grau de importância que
extensões como HTML, PDF e ODF.
XML na visão de Graves (2003, p. 02) “[...] é uma linguagem usada para representar
dados como uma string de texto”. É uma linguagem de marcação que tem por objetivo
padronizar dados e é caracterizada por separar conteúdo da apresentação.
Segundo o autor é importante ressaltar que XML não veio substituir o HTML, pois
esse tem como foco a exibição da informação e XML na descrição dos dados. Como XML
provê a separação entre apresentação e conteúdo, possibilita que o documento seja
7
apresentado de diversas formas, simplesmente aplicando folhas de estilos distintas, o que
permite desenvolvimento flexível de documentos definidos pelo usuário.
Deitel et. al. (2003) afirmam que um programa que consegue ler dados XML consegue
compreender a descrição dos dados, sendo possível então o processamento por uma aplicação,
fazendo com que desenvolvedores utilizem cada vez mais esse formato em suas aplicações.
A marcação é baseada em tags que se distinguem dos dados por estarem precedidos
por “<” e “>” como, por exemplo, <TCC>. Portanto, um documento é composto de tags e
dados que formam os elementos, como explicam os autores Moreira et. al. (2007).
Na visão dos autores Deitel et. al. (2003) os elementos são formados da seguinte forma
<elemento> dado </elemento>, sendo que sempre deve ser inicializado pelo caractere “<“
vindo logo em seguida a identificação do dado. Quando não se tratar mais do dado, deve ser
aberta nova tag e logo após deve vir uma barra, que irá definir que se trata de um elemento de
fechamento.
O elemento é o bloco básico em um documento XML. Um documento XML é
composto por um elemento chamado raiz, que fica mais externo e que, normalmente, possui
subelementos que podem possuir outros subelementos, formando a hierarquia do documento,
publicado no site XML Technology (2009).
Figura 1. Exemplo XML
A Figura 1 mostra um exemplo de documento XML que possui uma lista de pedidos,
na qual cada pedido possui um cliente, um campo que determina do que se trata aquele pedido
e um código de identificação do pedido.
Os documentos XML podem ser classificados em duas categorias: os bem formados e
os válidos, publicado no site W3Schools (2004). Um XML é bem formado se obedecer a um
conjunto de regras mínimas como:
Todos os documentos devem conter a "declaração XML";
Todos os documentos devem conter somente um elemento raiz;
Todos os elementos devem ter uma tag de fechamento;
XML é case sensitive; e
8
Os elementos XML devem estar corretamente aninhados.
Enquanto que um documento é válido quando for um documento bem formado e
também obedecer à estrutura imposta por um DTD (Document Type Definition – definição de
tipo de documento) ou XML Schema, que será explicado no Item 2.1.2 e 2.1.3.
2.1.1 Surgimento da linguagem XML
Na década de sessenta, existia uma busca por uma forma fácil de construir documentos
e compartilhá-los, tornando-os mais compatíveis com todos os computadores e sistemas
utilizados do mundo, conforme explica Ray(2001).
O autor ressalta que assim surgiu a linguagem chamada GML (Generalized Markup
Language – linguagem de marcação genérica) criada pela IBM para dar suporte a aplicativos
que processavam documentos. Essa linguagem de marcação surgiu da necessidade que existia
na época em armazenar grandes quantidades de informação de diversos temas. Contudo, a
aceitação desta linguagem não foi ampla, já que não foi aquilo que os desenvolvedores
esperavam.
Deitel et. al. (2003) afirmam que após, em 1974, a SGML (Standard Generalized
Markup Language – linguagem padrão de marcações genéricas) foi criada e aprimorada pela
ISO para atender aos requisitos de independência dos sistemas que lidavam com as
incompatibilidades com os sistemas da época. Em 1986, a ISO reconheceu o modelo
desenvolvido pela IBM e a partir de então, tornou-se a linguagem de marcação padrão para
muitos tipos de documentos, distribuídos pelo mundo.
Ainda na visão dos autores a SGML foi projetada para separar conteúdo da
apresentação, sendo possível a adaptação de um grande leque de problemas originando
diversas aplicações. Uma dessas aplicações aliou a linguagem de marcação e o hiperlink
criando uma nova linguagem chamada de HTML que foi utilizada para um novo serviço da
Internet, a Web.
A HTML logo se tornou popular, já que era fácil e simples de ser utilizada. Além da
facilidade, ela suportava algumas falhas dos criadores que, mesmo assim, continuavam
representando seus documentos de forma desejável, conforme publicado no site do XML
Technology (2009).
A mesma publicação explica que com o aumento do uso da Internet, e como cada vez
mais se desejava efetuar troca de dados pela Web com vídeos, fotos, áudios ou textos,
percebeu-se uma necessidade de padronização para gerar representações de documentos, as
9
quais fossem mais claras e precisas, fazendo com que as empresas buscassem soluções para
seus próprios navegadores. que a HTML por si só não suportava.
Esses recursos foram chamados plugins e eles possuíam a capacidade de representar
áudio, vídeo e outras formas de documentos Web. No entanto eles possuíam um problema,
cada utilização de vídeo ou áudio deveria possuir o seu próprio plugin, o que diminuía a
eficiência do sistema, na explicação dos autores Deitel et. al (2003).
Na visão de Quin (2009), chegou-se um ponto que o HTML não estava mais sendo
suficiente, por possuir apenas recursos de apresentação. Com isso, como resultado de um
esforço coordenado pela W3C buscando uma linguagem que pudesse satisfazer as
necessidades de interoperabilidade, escalabilidade e de fácil extensão deu origem ao XML.
Os objetivos iniciais dessa linguagem eram torná-la uma ferramenta que possuísse a
capacidade SGML e conseguisse aceitar HTML. Nessa nova linguagem, desenvolvedores de
todo o mundo poderiam criar seus programas em suas linguagens prediletas e, logo após,
representariam suas informações geradas por esses programas, por meio de documentos mais
flexíveis e simples de se entender, conforme explica Ray (2001).
Segundo Deitel et. al. (2003) as principais vantagens do XML em relação HTML, no
que se refere ao tratamento da informação é que no HTML o conteúdo se mistura com a
apresentação, e também a linguagem não permite compartilhar informação com todos os
dispositivos, como celulares ou computadores, pois a apresentação da tela depende da
tecnologia que está sendo utilizada.
Deitel et. al. (2003) dizem ainda que aliado a isso, HTML tem um número de
marcações pré-estabelecidas, enquanto que no XML as tags têm a liberdade de conter
qualquer dado (metadados) referente à informação a ser armazenada, o que permite a XML
ser utilizada de forma distribuída pela Web, podendo ser utilizados por diversos aplicativos e
a alterados para atender a diversas necessidades.
Outro fator que determinou a linguagem XML como uma linguagem de padronização
é o fato de ela possuir compatibilidade com mais de um conjunto de caracteres. Isso permite
que outros países que possuem caracteres especiais em seu idioma como gregos, possam
utilizar a ferramenta usando sua própria forma de linguagem.
2.1.2 Definição de tipo de documento (DTD)
Conforme explicado no site W3schools (2004), o propósito do DTD é de definir a
estrutura correta de construção de um documento XML. DTD define a estrutura do
10
documento com uma lista de atributos e elementos que são utilizáveis. Eles não são
declarados na sintaxe XML e sim na gramática própria.
O documento XML não tem obrigação de ter um DTD correspondente, porém o uso
de DTDs é frequentemente recomendado para garantir a conformidade do documento,
especialmente em transações B2B (business-to-business – negócios entre empresas usando a
Internet), nas quais os documentos XML são trocados, explicam os autores Deitel et. al.
(2003).
Figura 2. Exemplo documento XML com DTD interno
Fonte: W3Schools (2004)
No exemplo da Figura 2 os elementos podem ser interpretados da seguinte forma: o
elemento !DOCTYPE define o elemento raiz do documento. Um documento só pode conter
um elemento raiz que marca o início do documento e é considerado o pai de todos os outros
elementos, que são aninhados entre a tag inicial e final. Tudo que estiver após os colchetes
constitui o subconjunto interno, conforme publicado no site W3Schools (2004).
Ainda se tratando da Figura 2, o próximo elemento encontrado é !ELEMENT note que
define o que esse elemento deve conter, respeitando a ordem informada no DTD. De acordo
com o site W3Schools (2004) ainda poderia estar incluído um sinal de mais (+), asterisco (*),
ou ainda, o ponto de interrogação (?) que serve para indicar a frequência com que os
elementos aparecem no documento. Se aparecer um sinal (+) o elemento pode aparecer um
número qualquer de vezes, mas deve aparecer pelo menos uma vez. Caso apareça o sinal (*) o
elemento é opcional, mas só pode aparecer uma vez, ou seja, indicando se é zero ou um.
Em seguida, o elemento “#PCDATA” determina o conteúdo permitido pelo elemento.
Refsnes (2005) explica que a palavra chave PCDATA quer dizer que o elemento deve conter
caracteres sintaticamente analisáveis. Esses dados serão analisados pelo analisador de XML,
11
portanto qualquer texto de marcação (<, >, &) será tratado como marcação. O autor afirma
que a diferença entre CDATA e PCDATA é que as seções CDDATA são simplesmente
ignoradas pelo analisador e a correção da forma dessas seções não é verificada.
Refsnes (2005) diz ainda que um DTD pode ser declarado dentro do próprio
documento XML, ou como referência externa. Com uma declaração DTD, cada documento
XML pode carregar uma descrição do seu formato. Também pessoas de diferentes grupos
podem concordar em utilizar um DTD padrão para trocar dados. A aplicação pode utilizar um
padrão DTD para verificar se aqueles dados originados de outras fontes podem ser
considerados como válidos. Como o documento DTD, tem uma sintaxe especial, diferente da
sintaxe XML, surgiu uma nova maneira de estruturar documentos XML, o XML Schema que
é uma linguagem um pouco mais complicada de definir, porém, além de ser em linguagem
XML, permite definir outros tipos de dados como campos numéricos e data.
2.1.3 Esquema XML
No esquema XML os dados podem ser padronizados utilizando tipos de dados que
restringem o que cada tipo de dado pode receber. Se um aplicativo ler um determinado
número, ele irá interpretá-lo de uma maneira diferente que uma pessoa. Os tipos de dados
fornecem uma maneira para padronizar esses dados, na visão dos autores Chang et. al. (2001).
O autor explica que a linguagem de definição do XML Schema, a XSDL, fornece
diversos mecanismos para a criação de novos tipos de dados pela restrição dos existentes,
como strings com “n” caracteres. A XSDL define os tipos dos elementos e atributos em XML
usando elementos com os nomes “element” e “atribute” para definir seu tipo. A Figura 3
exemplifica como poderia ser representado.
Figura 3. Exemplo XML Schema
Para definir quando utilizar DTD ou XSDL dependerá do desenvolvimento de
aplicativos e do que será preciso no banco de dados. As DTDs podem ser utilizadas para que
12
um receptor do documento XML consiga verificar se o documento corresponde à definição de
tipo, se ele foi danificado, ou ainda pode empregá-las na alocação de estruturas de dados para
processamento, ou seja, se preocupando apenas com a definição da estrutura do documento.
Já a XSDL, além da estrutura, pode ser também analisado os tipos de dados de um
documento, publicado no site W3Schools (2004).
Graves (2003) explica que para um aplicativo possa manipular um esquema é
necessária a criação de um conjunto de regras simplificadas de mapeamento da estrutura
XML. As regras de mapeamento descrevem como os elementos e atributos de um documento
XML serão usados na criação dos campos de um objeto.
O autor ressalta que essas regras de mapeamento podem ser geradas utilizando um
código genérico que a partir do documento XML gere automaticamente os objetos, ou crie
documentos XML a partir dos objetos em um aplicativo. A Figura 4 mostra um exemplo de
documento XML para que efetuar o mapeamento.
Figura 4. Documento XML
Fonte: Adaptado de Graves (2003)
O mapeamento a partir de um documento XML, "@" irá representar um atributo, “[]”
uma restrição do caminho e “/*” todos os subelementos de um elemento. A Tabela 1 é um
exemplo de especificação de objeto, na qual o elemento automóvel vira uma sub-árvore e
possui os seguintes subelementos: fábrica, modelo, ano, preço, cor, rádio, e um conjunto de
opcionais que poderá formar uma nova lista com vários opcionais de um automóvel.
Tabela 1. Especificação do Objeto
Automóvel
Fábrica String,
Modelo String,
Ano String.
Preço Número,
Cor String,
Rádio String,
Opcionais Conjunto de Strings.
Fonte: Adaptado de Graves (2003)
13
Com essa etapa concluída será possível fazer a relação do campo com o caminho que é
o mapeamento do documento XML para campos do objeto, como mostra a Tabela 2.
Tabela 2. Mapeamento do documento XML para campos do objeto
Campo Caminho
Fábrica @fabrica,
Modelo @modelo,
Ano @ano,
Preço @preco,
Cor @cor,
Rádio Opcionais [categoria= “radio”]
Opcionais Opcionais/*
Fonte: Adaptado de Graves (2003)
Em seguida, devem ser criados métodos de acesso para campos objetos, considerando
a cardinalidade dos campos e todos os objetos necessários. Em exemplos mais complexos,
pode-se utilizar um conjunto de objetos e ao invés de fazer o mapeamento para cada
elemento, faz apenas para os objetos. Poderia ser inserido no exemplo dos automóveis, um
elemento proprietário, com um atributo nome e um elemento de contato, conforme Tabela 3.
Tabela 3. Especificação do Objeto
Proprietário
Nome String,
Contato String,
Automóveis Conjunto de automóveis
Fonte: Adaptado de Graves (2003)
Graves (2003) afirma que para o mapeamento das regras existem diversas maneiras de
implementação. Pode ser criado um aplicativo que use um analisador XML e crie os objetos
durante a análise. Também pode ser utilizadas folhas de estilo XML para implementar as
regras de mapeamento. Ao utilizar as folhas de estilo, os elementos podem ser reescritos em
um elemento específico, que poderá então ser utilizado por um aplicativo mais genérico na
criação dos objetos.
2.1.4 Corpo do documento
Na visão dos autores Chang et. al. (2001) um documento XML inicia pelas definições
estipuladas por um XML Esquema ou um DTD. Além disso, um documento é composto por
um elemento raiz, elementos aninhados, instruções de processamento, conteúdo, atributos,
comentários, referências a entidades e outros.
14
Existem também atributos internos que definem que os dados contidos entre os
elementos sejam representados preservando os espaços em branco.
Outros termos associados à API (application programming interfaces – interface de
programação de aplicativos) de XML podem ser classificados em categorias como explicam
Chang et. al. (2001), de modo a pertencer às áreas:
DOM (Document Object Model);
SAX (Simple API for XML);
XML Namespaces;
XSLT (Extensible Stylesheet Language Transformation); e
XML Linking, Pointer e Path.
As APIs, em sua maioria são mantidas pelas especificações da W3C, o que possibilita
que desenvolvedores de aplicativos possam usar interfaces de programação padrão.
2.1.4.1 APIs DOM (Modelo de objeto de documento)
Deitel et. al. (2003) explicam que um documento XML é estruturado de forma que as
tags sejam aninhadas de forma ordenada. Com isso, o documento pode ser visto como uma
árvore cujas folhas consistem nas tags, bem como nas informações correspondentes contidas
entre elas. Quando o analisador percorre o documento XML, é possível formar uma
representação da árvore do documento XML na memória, chamada de DOM.
A W3C criou um conjunto de APIs DOM para acessar e navegar por essa árvore. Os
componentes dessa árvore são o elemento raiz do documento, os nós filhos e irmãos, os
elementos, os atributos, os nós de texto que representam o conteúdo textual de um elemento
ou atributo, as seções CDATA para marcar blocos de texto que, de outra forma, seriam vistos
como marcações, os comentários, as referências a entidades e instruções de processamento,
conforme analisado pelos autores Chang et. al. (2001). Os analisadores XML que fornecem
todas as APIs DOM são considerados compatíveis com o padrão DOM são chamados de
analisador baseado no DOM.
A XML foi projetada para ser uma tecnologia viva e dinâmica, um programador pode
modificar a estrutura de árvore, o que permite ao desenvolvedor acrescentar dados, removê-
los, e consultá-los de maneira similar a um banco de dados, conforme explicam Deitel et. al.
(2003).
15
Na visão dos autores Chang et. al. (2001) um analisador baseado no DOM permite que
uma biblioteca para uso em programas faça com que os dados de um documento XML sejam
modificados e acessados pela manipulação dos nodos de uma árvore DOM.
Os analisadores são escritos em diversas linguagens. Muitos aplicativos possuem
analisadores internos. Como exemplo de analisadores pode ser citado: JAXP, XML4J, Xerces,
MSXML, 4DOM, XML:DOM, entre outros.
2.1.4.2 APIs SAX (Simple API for XML)
Na visão dos autores Deitel et. al. (2003) a SAX foi desenvolvida por membros da
mailing list XML-DEV em maio de 1998. Os autores explicam ainda que SAX é uma API
baseada em eventos onde a aplicação precisa criar um modelo de objetos personalizados para
armazenar toda a informação própria de seus documentos XML e também um interpretador
dos eventos, gerados pelo próprio "parser" SAX.
Deitel et. al. (2003) afirmam que devido o modelo SAX não precisar carregar uma
árvore interna do documento XML, resulta em melhor desempenho e menor consumo de
memória em comparação ao DOM.
Muitos analisadores DOM utilizam um analisador baseado em SAX para efetuar a
recuperação do documento, porém para efetuar modificações no documento se torna uma
implementação muito complexa e como não há a necessidade da árvore estar na memória,
acaba consumindo menos memória fornecendo melhor desempenho. Com isso os
programadores acabam construindo a árvore DOM para a manipulação do documento e
utilizam SAX apenas para a recuperação e consulta de dados do documento XML, de acordo
com Chang et. al. (2001).
2.1.4.3 APIs Namespaces
Chang et. al. (2001) afirmam que namespaces podem permitir nomes idênticos para
elementos ou atributos. Por exemplo, quando dois documentos diferentes que possuam
elementos com o mesmo nome, forem adicionados juntos, haverá um conflito de nomes de
elementos.
Namespaces provém um método para evitar esse conflito de nomes de elementos onde
um prefixo pode ser utilizado para diferenciar os elementos, criando dois tipos de elementos
diferentes conforme publicado no site W3Schools (2004). O autor explica ainda que aliado a
16
isso pode ser utilizado um atributo "xmlns" para dar ao prefixo do elemento um nome
qualificado associado com um namespace.
O atributo namespace é colocado no tag de abertura de um elemento e tem a seguinte
sintaxe: xmlns:namespace-prefix="namespace". A figura 5 ilustra um exemplo de Namespace,
onde o próprio namespace é definido usando um endereço na Internet, onde o namespace raiz
foi definido e todos os elementos e atributos definidos abaixo desse elemento serão associados
ao namespace, W3Schools (2004). No exemplo da Figura 5 os atributos nome, largura e altura
são atributos do elemento raiz "table".
Figura 5. NAMESPACES
Fonte: W3Schools (2004)
Quando um namespace é definido na tag abertura de um elemento, todos os elementos
filhos com o mesmo prefixo são associados com o mesmo namespace. Um namespace não é
usado pelo "parser" para buscar a informação. O único propósito é dar ao namespace um
nome único. Entretanto muito frequentemente usam o namespace como um ponteiro para uma
página Web real contendo informação sobre o namespace, Chang et. al. (2001).
2.1.4.4 APIs de analisador
Graves (2003) afirma que programas aplicativos chamam a API de análise para ler um
documento XML e fornecer acesso ao conteúdo e estrutura por APIs DOM ou SAX.
Geralmente, as funções de inicialização e terminação também precisam ser chamadas junto
com a função de análise.
O autor diz ainda, que podem ser definidos com algumas funções de inicialização
como descartar espaços em branco e ativar a validação antes que a função de análise seja
chamada pelo programa aplicativo. Existem, por exemplo, alguns analisadores XML como os
da Oracle, têm validação opcional, o que significa que os usuários podem especificar a
validação ou não antes de chamar a função de análise.
17
2.1.4.5 APIs XSLT (Extensible Stylesheet Language Transformation)
Nas visões de Chang et. al. (2001) a XSLT é utilizada para ajustar a apresentação e
formatar um documento XML. Ela permite a aplicação de folhas de estilos, criadas em XML
definidos pelo usuário e tags/funções XSLT, a documentos XML, por um processador XSLT.
Basicamente, o processador correlaciona padrões da folha de estilo no documento XML, e em
seguida, aplica comandos para delimitar os dados encontrados e gerar resultados como um
documento XML separado.
2.1.4.6 XML Linking, Pointer e Path
Para os autores Deitel et. al. (2003) XML linking fornece mecanismos para hyperlinks
como os de HTML e os mais complexos podem envolver vários documentos. Os links podem
envolver referências a recursos ou documentos externos, assim como referências dentro de
documentos XML.
Os autores dizem ainda que os links da linguagem Xlink, não são armazenados dentro
dos documentos que as vinculam, podem ficar em um documento separado e vincular regiões
explícitas de outros documentos.
A vinculação é feita utilizando a linguagem Xpointer. Para utilizar Xlink deve ser
declarado o namespace Xlink no alto do documento XML, conforme explicam Chang et. al.
(2001). O autor explica que a Xpointer permite que os hiperlinks apontem a uma parte mais
específica no documento original de XML. Assim é possível que um link aponte para uma
região aleatória do documento sem respeitar a propriedade ou organização.
Outra especificação utilizada pela Xpointer é a Xpath que é um conjunto de regras de
sintaxe para definir partes de um documento XML. Xpath então utiliza expressões de
caminhos para identificar nós em um documento XML. Essas expressões de caminhos se
assemelham com as encontradas em sistemas de arquivos de um computador, conforme
explicado por Deitel et. al. (2003).
O autor ressalta que ela possui uma biblioteca de funções para trabalhar com strings,
números e expressões booleanas. Pode ser utilizado para buscar elementos que tenham, por
exemplo, um valor maior que determinado valor. Para localizar nós, Xpath utiliza uma
expressão padrão que é uma lista de nomes de elementos filhos separada por barras que
descreve o caminho através do documento XML. O padrão seleciona elementos que
18
combinam com o caminho. Pode além de localizar nós, elementos desconhecidos, seções,
vários caminhos e atributos. A Figura 6 mostra um exemplo de utilização da Xpointer.
Figura 6. XPOINTER
Fonte: W3Schools (2004)
Aplicando a expressão XPATH na Figura 6, pode ser selecionado o elemento raiz do
documento, como catalog: /catalog. Outro exemplo, se necessário buscar todos os elementos
price de todos os elementos cd do elemento catalog: /catalog/cd/price, conforme publicado no
site W3Schools (2004).
2.1.5 Razões para utilizar XML
Para Graves (2003) a XML originou-se da dificuldade na publicação eletrônica em
larga escala isolando o conteúdo da formatação. Ao separar o conteúdo de um documento de
como ele deve ser formatado simplifica o desenvolvimento e a manutenção fazendo com que
equipes com diferentes experiências consigam trabalhar independentes, mesmo sem o
conhecimento da linguagem em que o sistema foi desenvolvido.
O autor explica ainda que XML pode também ser utilizada na transferência de dados.
Aplicativos podem utilizar XML para transferir dados entre o usuário e a Web, ou ainda, entre
a própria Web e aplicativos. Se for aliada uma folha de estilo (CSS), para manipular a
apresentação, a um documento XML, ele também pode ser facilmente utilizado para
visualização.
Na visão dos autores Moreira et. al. (2007) um documento XML pode representar
diversas formas de documentos, desde os mais rígidos com uma estrutura totalmente
inflexível com um conjunto de hierarquias, até mesmo uma carta de amor que pode ter
19
diversas maneiras diferentes de serem formatadas. Pode inclusive ter a junção dos dois no
mesmo documento.
Moreira et. al. (2007) afirmam ainda que as duas principais vantagens sobre as outras
linguagens é que ela é muito extensiva e expressiva. Qualquer tema pode estar bem
representado com a XML. Caso necessário transferir dados entre sistemas, e a estrutura dos
dados puder ser alterada, a XML pode ser utilizada para armazenar os relacionamentos
complexos.
Na visão de Deitel et. al. (2003) XML pode ser utilizado nas páginas Web dinâmica ou
estática. A facilidade da separação de dados da formatação facilita muito, mesmo em sites
estáticos. Já em sites dinâmicos, permite o desenvolvimento de aplicações para a Web em três
camadas, pois os dados de um arquivo XML podem ser distribuídos para outras aplicações,
objetos ou servidores de aplicação. Também pode ser considerado como vantagem, o fato do
processamento ficar a cargo do cliente e não do servidor, com isso reduzindo o tráfego no
servidor e o tempo de resposta.
A compreensão de dados também pode ser facilmente utilizada, pois as tags usadas
para definir a estrutura de dados possuem uma natureza repetitiva. A necessidade de
compreensão é dependente da aplicação e da quantidade de dados a serem transferidos entre
clientes e servidores, explicam Deitel et. al.(2003).
Os documentos XML também podem ser utilizados de maneira elementar, não
existindo a necessidade de reenvio de todos os dados apenas porque ocorreu uma pequena
alteração em todo o conjunto de dados.
Existem também as razões comerciais para a utilização do XML, como publicado no
site da Microsoft, “Porque as empresas de hoje lidam com muitos dados e eles provem de
várias fontes e vários formatos: banco de dados, páginas da Web, arquivos de planilhas e e-
mail. O XML permite trabalhar com dados de mais fontes e obter mais desses dados”.
Atualmente diversos aplicativos têm utilizado XML. Alguns deles bem conhecidos como:
RSS – Formato padrão para publicação de notícias;
Web Services – Padrão de publicação de serviços na internet;
Podcasts – Publicação de arquivos de mídia; e
AJAX – Tecnologia que permite maior interatividade em páginas Web.
Além desses e outros serviços, praticamente todo tipo de informação que precise ser
importada ou exportada por sistemas, portais e sites vem usando o padrão XML para sua
construção, Deitel et. al. (2003).
20
Aliado a tudo isso, foi publicado uma lista no site XML Technology (2009) com os
benefícios de um XML bem formado:
Redução de requisitos de armazenamento;
Redução de custo e requisitos de banda de dados;
Aumento de Performance;
Aumento de interoperabilidade com sistemas eficientes;
Redução do tempo e custo de desenvolvimento para Sistemas mais eficientes; e
Aumento do tamanho do mercado para Soluções XML.
2.2 FORMAS DE ARMAZENAMENTO DE DADOS XML
Na visão de Moreira et. al. (2007) existem diversas formas de se armazenar
documentos XML:
Armazenamento do tipo Flat File: prove um acesso hierárquico aos dados através da
estrutura de diretórios do sistema de arquivos e após pela estrutura de elementos dos
documentos XML. É uma forma de armazenamento simples que pode ser acessada facilmente
através de editores de texto e ferramentas XML. A desvantagem é que devido não ter um
aplicativo gerenciando esses arquivos, os dados ficam vulneráveis e as consultas ficam mais
difíceis de serem realizadas afetando o desempenho dos documentos XML.
Armazenamento baseado em tabelas: deve ser feito um mapeamento dos dados de
um documento para um banco de dados relacional. Um documento pode ser mapeado para
uma simples tabela ou para um grupo de tabelas. Cada elemento complexo é representado por
uma coluna da tabela e cada elemento simples é representado por uma coluna que representa
seu pai na hierarquia do documento. Para essa forma ser vantajosa, a estrutura do documento
não pode ser importante. Caso necessário gerar novamente o documento, os comentários e a
hierarquia do documento podem ser perdidos, não sendo a melhor maneira de armazenar.
Armazenamento baseado em objetos: deve ser feito um mapeamento dos dados de
um documento XML para um banco de dados objeto relacional. Esse mapeamento irá realizar
a modelagem na forma de uma árvore de objetos específicos para os dados do documento.
Elementos complexos serão modelados como classes e os elementos simples serão modelados
como atributos da classe. O modelo será então mapeado para banco de dados relacionais
usando técnicas de mapeamento objeto-relacional, ou seja, as classes serão mapeadas para as
tabelas e os atributos da classe para as colunas.
21
Armazenamento do tipo nativo: é o mais adequado quando os dados possuem uma
estrutura regular, pois se a estrutura for irregular, o mapeamento pode gerar muitas colunas
com valores nulos ou em um grande número de tabelas, sendo, portanto ineficiente. A
vantagem é a velocidade de recuperação. A estratégia de armazenamento usada em alguns
bancos de dados XML nativos, armazenam o documento XML inteiro ou utilizam ponteiros
físicos, invés de lógicos, entre as partes do documento.
2.3 BANCO DE DADOS
Crespo (2007) ressalta que na visão de Andy Mendelson, vice-presidente sênior de
Tecnologias de Servidor de banco de dados da Oracle, seus clientes mais do que nunca têm
enfrentado desafios, tais como rápido crescimento dos dados, aumento da integração entre
eles e pressões no custo da tecnologia para conectividade.
O autor afirma que ao utilizar banco de dados, as empresas poderão assumir o controle
de suas informações empresariais, tendo uma melhor visão dos negócios e adaptando-se com
rapidez a um ambiente competitivo que passa por grandes mudanças.
Ramakrishnan (2008) explica que a quantidade de informações disponíveis aumenta a
cada dia, e os dados como ativos organizacionais são amplamente reconhecidos, sendo
necessárias ferramentas que simplifiquem as tarefas de gerenciamento dos dados e que
permitam extrair informações úteis de forma oportuna, senão esses dados podem acabar se
tornando um problema.
Silberschatz (1999) explica que assim surgiram sistemas gerenciadores de banco de
dados ou SGBDs, que fornecem acesso ao banco de dados e auxiliam na manutenção e
utilização desses dados. São considerados operações do SGBD inserção, exclusão,
recuperação e atualização. Também podem existir outros softwares que interagem com o
SGBD como, por exemplo: ferramentas do usuário final, de administração, geradores de
relatórios, softwares de backup entre outros. Além disso, O SGBD assegura a integridade
física dos dados e das transações efetuadas sobre o banco.
O autor ressalta ainda que o SGBD deva manter os usuários de banco de dados longe
do hardware aonde foi implementado, e fornece controle centralizado das informações, o que
protege os dados de erros que possam ter sido causados por usuários ou aplicações. Isso
também implica em inflexibilidade em relação aos dados, pois os usuários ficam impedidos
de efetuar determinadas operações diretamente no banco.
22
Abaixo uma relação com outras funções dos SGBDs, Chang et. al. (2001).
Controlar redundância;
Compartilhamento de dados;
Independência de dados;
Segurança;
Backup e recuperação as falhas;
Forçar restrições de integridade;
Aumentar a disponibilidade e produtividade; e
Flexibilidade, padronização.
Na opinião do autor Silberschatz (1999), um SGBD é uma coleção de arquivos e
programas inter-relacionados que permitem ao usuário o acesso para consultas e alterações
desses dados. O maior benefício é a abstração dos dados, onde o usuário não precisa saber
determinados detalhes sobre a forma de armazenamento e manutenção desses dados, assim
criando níveis de acesso aos dados conforme abaixo:
Nível físico – nível mais próximo do hardware. Descreve como esses dados estão de
fatos armazenados. No nível físico, complexas estruturas de dados de baixo nível são descritas
em detalhes. São usados por profissionais que fazem sintonia de banco de dados, procurando
aperfeiçoar o desempenho.
Nível lógico – é um nível médio de abstração. Descreve quais dados estão
armazenados no banco e seus relacionamentos. Nesse nível o banco inteiro é descrito em
termos de um pequeno número de estruturas relativamente simples. Embora as
implementações de estruturas simples no nível lógico possam envolver complexas estruturas
do nível físico, o usuário do nível lógico não precisa se preocupar com isso. Esse nível é
utilizado por administradores de banco de dados que necessitam tomar decisões sobre quais
informações devem pertencer ao banco de dados.
Nível visão ou externo – é o nível mais alto da abstração dos dados. Usuários que não
conhecem todas as informações do banco de dados, apenas parte do banco. Os usuários que
utilizam o nível visão não necessitam conhecer como os dados são armazenados e mantidos
nos SGBD.
A Figura 7 mostra um exemplo dos níveis de abstração, abrangendo do nível mais
externo até chegar aos níveis mais internos, chegando até a gravação em disco dos dados.
23
Figura 7. Os três níveis de abstração dos dados
Fonte: Silberschatz (1999)
Sendo assim, além de diversos níveis de abstração, também é possível utilizar
diferentes técnicas, aplicando diferentes conceitos ao construir modelos. Esses conceitos
podem ser denominados abordagem de modelagem, como explica Heuser (2004). O primeiro
modelo é o conceitual, que é uma descrição do banco de dados independente do SGBD. Esse
modelo registra quais dados podem aparecer no banco, porém não apresenta de que forma foi
armazenado.
O autor explica que o chamado modelo lógico, é o utilizado por usuários de um
SGBD, como por exemplo, administradores e DBAs (database administrator). O modelo
lógico depende do SGBD escolhido, e é nesse modelo que devem ser definidas as tabelas que
o banco irá conter e, os nomes das colunas.
O último modelo é o modelo de organização que tem como objetivo representar
objetos de uma empresa como produtos, vendas, ordem de compra, e outros, em uma base de
dados. Dessa forma é possível envolver o usuário na especificação do banco de dados, pois
ainda não estão definidos detalhes somente compreensíveis por técnicos, mas sim objetos de
uma organização. Esse envolvimento permite uma qualidade de softwares muito melhores,
24
pois é quem melhor conhece a organização. Portanto são modelos usados para descrever a
organização, conforme explica Heuser (2004).
2.3.1 Banco de dados relacionais com suporte XML
Com base em Ramakrishnan (2008), o modelo relacional foi proposto em 1970.
Naqueles tempos existiam apenas dois modelos de banco de dados (modelo hierárquico e de
rede). Foram desenvolvidos protótipos de sistemas gerenciamento de dados relacional em
projetos de pesquisa pioneiros na IBM e UC-Berkeley e após vários fabricantes estavam
oferecendo a tecnologia.
O autor afirma que atualmente os bancos de dados relacionais dominam o mercado de
banco de dados e de SGBDs. Líderes de mercado como Oracle, a família DB2 da IBM, o
Informix, Sybase, Access e o SQLServer da Microsoft, PostegreSQL, são alguns exemplos de
banco de dados relacionais.
Segundo Graves (2003), um banco de dados relacional organiza seus dados em
relações. Cada relação pode ser vista como uma tabela, onde cada coluna corresponde a
atributos da relação e as linhas correspondem as tuplas ou elementos da relação. Pode ser
comparado com os sistemas de arquivos, onde as tuplas são denominadas registros e os
atributos, campos.
O autor explica que assim iniciantes podem entender o conteúdo de um banco de
dados e possibilita o uso de linguagem alto nível para consultar os dados. As principais
vantagens do modelo relacional em relação aos modelos de dados mais antigos é a
simplicidade na representação dos dados e a facilidade de expressar consultas.
Graves (2003) explica que os sete operadores em banco de dados relacionais são a
seleção, a projeção, a junção o produto, a união, a diferença e a intersecção. Há duas
restrições de integridade independente do banco de dados:
Nenhum componente de chave primária de um relacionamento básico pode
aceitar valores nulos; e
O banco de dados não pode ter valores de chave externa sem uma
correspondência.
O principal conceito do modelo relacional é a relação que é composta de instância da
relação e esquema da relação. A instância da relação é um conjunto de tuplas ou registros que
pode ser visto como uma tabela e o esquema descreve as colunas dessa tabela e especifica o
25
nome da relação, o nome de cada campo (coluna ou atributo), e o domínio, como afirma
Graves(2003).
Ramakrishnan (2008) afirma que uma das razões pelo qual o modelo com
relacionamentos se tornou popular é que ele restringia claramente todos os registros de um
relacionamento de modo que tivessem uma assinatura abstrata semelhante, ao invés de vários
ponteiros tipificados.
Ex: Cidade (codigocidade: string, nome: string, estado:string)
Esse exemplo significa que o campo chamado codigocidade tem um domínio chamado
string. O conjunto de valores associados ao domínio string é o domínio de todos os strings de
caracteres.
As instâncias de uma relação são os dados ou tuplas (registros) de uma tabela, onde
cada tupla tem o mesmo número de campos que o esquema de relação. Uma instância pode
ser considerada uma tabela, na qual cada tupla é uma linha e todas as linhas têm o mesmo
número de campos Ramakrishnan (2008), como por exemplo, a Tabela 4 que mostra
instâncias de uma tabela que armazena cidades tendo um código e estado relacionados.
Tabela 4. Exemplo de instância da relação da tabela cidade
Código da Cidade Nome Estado
00001 Videira SC
00002 Itajaí SC
00003 São Paulo SP
00004 Curitiba PR
00005 Porto Alegre RS
Graves (2003) afirma que aliando a tecnologia dos bancos de dados relacionais e a
distribuição de dados XML será possível efetuar consultas complexas que podem ser escritas
em SQL, que é a linguagem padrão de consultas em SGBDs relacionais. Os relatórios podem
ser formatados como XML para fornecer muitas visões dos dados. Isso é útil quando os
aplicativos necessitam de visões especificas no banco dados. Os sistemas podem procurar
informações especificas que agradem a sua estrutura de dados, receberem os dados como
XML e alimentando os objetos do sistema.
Segundo Graves (2003) outra vantagem inclui a fácil interoperabilidade com outros
bancos relacionais, gerenciamento de transações e mecanismos de recuperações sofisticadas e
também várias ferramentas que dão suporte à ferramenta. Será muito apropriado utilizar
quando ele puder ser acessado por aplicativos que interagem com outros bancos de dados
relacionais.
26
Graves (2003) explica que existem diferentes maneiras para armazenamento de dados
em um SGBD relacional. A primeira abordagem é banco de dados relacional com granulação
pequena, em cada elemento e atributo pode ser acessado individualmente. A segunda usa a
granulação grande, na qual o documento é manipulado em sua totalidade.
2.3.1.1 Armazenamento com granulação pequena
Nessa abordagem, para cada estrutura do documento é fornecida uma identidade
exclusiva no banco de dados relacional. Cada elemento, atributo e região de dados podem ser
acessados um a um, alterados ou excluídos com um efeito mínimo sobre outras estruturas do
documento. Isso fornece mobilidade e facilidade de acesso para operações específicas do
SGBD XML como nos relacionais tradicionais, conforme explica Graves (2003).
A idéia é que cada tipo de estrutura possua sua própria tabela, inclusive uma tabela
para os documentos e uma para o relacionamento pai/filho entre os elementos e seus
subelementos.
Graves (2003) afirma que o esquema lógico é composto de duas fases. A primeira é
criar um esquema relacional no modelo de dados relacional e a segunda é normalizar esse
esquema. Um esquema lógico relacional é definido em termos dos nomes de relacionamentos,
nomes de colunas e domínios. Os nomes dos relacionamentos e colunas são familiares para as
pessoas que tem usado qualquer tipo de SGBD relacionais. Os nomes dos domínios são uma
parte integrante do modelo de dados relacional, mas não são implementados em base de dados
relacionais tradicionais. Dados como números, strings são domínios predefinidos no modelo
de dados relacional. Existem também domínios definidos pelos usuários que são os chamados
atômicos dentro do esquema ou se referirem a relacionamentos do esquema.
O esquema lógico é especificado no seguinte formato: NomeRelacionamento
(nomeColuna1 NOME_DOMÍNIO1, nomeColuna2 NOME_DOMÍNIO2). O esquema lógico
pode ser especificado conforme mostrado na Figura 8.
Figura 8. Esquema lógico no modelo de dados relacional usando a granulação pequena
Fonte: Graves (2003)
27
Na Figura 9 os domínios “CHILD_CLASS” e “CHILD_NODE” são usados para
simular a união dos domínios “ELEMENT” e “CHARDATA”. Para normalizar o esquema,
os domínios dos relacionamentos “DOCUMENT” e “ELEMENT” são eliminados com a
criação de identificadores exclusivos para cada relacionamento “doc_id” e “ele_id” dos novos
domínios atômicos definidos pelo usuário “DOC_ID” e “ELE_ID”.
Figura 9. Esquema Lógico normalizado
Fonte: Graves (2003)
Graves (2003) ressalta que no esquema normalizado, que a tabela de documentos
contém colunas para o nome, a identificação do documento e a raiz do elemento. Cada entrada
da tabela referencia a um documento no banco de dados.
O nome fornece uma identificação exclusiva do documento para aplicativos externos.
Isso é necessário para a rápida para a recuperação do documento quando forem executadas
pesquisas. A raiz do documento conecta a tabela de documentos ao elemento na tabela de
elementos que for a raiz da árvore de elementos do documento.
A tabela de elementos conecta as outras estruturas do documento. Cada elemento de
um documento possui um identificador exclusivo. Ter um identificador para cada elemento
simplifica o processo de pesquisa e cópia de documentos dentro do banco de dados, conforme
explica Graves (2003).
A figura 10 mostra às tabelas geradas depois de efetuadas as etapas de normalização
dos esquemas lógicos.
28
Figura 10. Esquema Lógico normalizado do banco relacional com granulação pequena para
armazenamento XML
Fonte: Graves (2003)
Na Figura 10 a tabela de elementos também contém colunas para o nome do tipo de
elemento (tag), o identificador do documento e o identificador do elemento pai. Assim é
possível capturar o valor da String do tipo de elemento, e o identificador de documento que se
refere ao documento ao qual o elemento é parte.
Segundo Graves (2003) elementos não podem ser criados sem que haja documentos
relacionados, pois senão vários aplicativos poderiam criar simultaneamente elementos
danificando o banco de dados. O identificador de elemento pai conecta os subelementos aos
elementos pais em uma estrutura de árvore. E cada elemento deve ter um elemento pai exceto
o elemento raiz, que é representado por um campo vazio ou nulo.
As tabelas de atributos contem o nome e o valor e uma referência para o identificador
do elemento para o qual ele é atributo. Também possui uma coluna de identificador e uma
referência ao identificador do documento. A tabela de filhos conecta os elementos da tabela
de elementos por meio do identificador do elemento e das colunas dos identificadores de
filhos. É uma maneira direta de acessar diretamente todos os subelementos e regiões com
dados formados por caracteres que sejam descendentes diretos de um elemento.
29
2.3.1.2 Armazenamento com granulação grande
Essa abordagem procura armazenar documentos de maneira integral. É semelhante ao
armazenamento de documentos em arquivos simples, porém essa abordagem tem a vantagem
de permitir que os documentos sejam referenciados dentro de outras estruturas do banco de
dados. Fornece ainda a segurança, o nível de recuperação e outros recursos do SGBD onde foi
feito o armazenamento.
Para esquema conceitual e lógico, um documento é definido com nome e corpo. O
nome é opcional e fornece um identificador exclusivo pelo qual o usuário pode se referir ao
documento. Segundo Graves (2003) o esquema lógico é composto de uma tabela chamada
documento com três colunas: um nome, identificador numérico, e um corpo.
Um identificador exclusivo é adicionado ao esquema nesse estágio para facilitar sua
integração a outras partes do sistema, e não é estritamente necessário. Para o autor o esquema
lógico para granulação simples é definido como: Document (nome STRING, corpo Text).
2.3.2 Banco de dados XML Nativo
Como explica Graves (2003, p.10), “banco de dados XML é um conjunto de
documentos XML que são armazenados em repositórios e podem ser manipulados.” Segundo
o autor, os documentos foram desenvolvidos para a comunicação entre pessoas, porém com o
advento dos computadores puderam ser utilizados para a comunicação.
Na visão dos autores Deitel et. al. (2003) os documentos XML podem ser classificados
de acordo com o propósito, ou seja, para processamento de documentos, quando o XML é
utilizado para capturar linguagens humanas como manuais, páginas da Web e folhetos de
propaganda. Nesse formato de documentos a estrutura é complexa e irregular e dá ênfase a
apresentação do documento.
Os autores afirmam que existe também o documento orientado ao processamento de
dados, usada para a transferência de dados. A apresentação dos dados é irrelevante e a
estrutura do documento não é importante e simples. São documentos que normalmente se
repetem muito. A XML é uma maneira eficiente de manipular esses documentos, pois em
ambos os casos é importante uma estrutura de hierarquias que são facilmente manipuladas e
que podem ser armazenadas em banco de dados.
30
Existem casos em que um documento pode abranger os dois modelos de
processamento, onde é necessária uma boa visualização do documento e também é um
documento que será utilizado por um sistema para manipular uma venda.
Graves (2003) explica que as diferenças serão mais claras no momento que abranger
as operações, pois as operações que abrangem um documento orientado a apresentação irão
abranger a busca do documento por completo, ou uma palavra, fazer uma alteração no
documento. Já em um documento orientado ao processamento de dados, permitirá a busca de
um trecho especificado do documento, a busca de uma combinação particular de documentos
ou a inserção de um novo elemento no documento.
No entanto, os bancos de dados XML são um conjunto de documentos orientados ao
processamento de dados. Segundo Graves (2003) as operações fornecidas pelo banco de
dados XML são mais destinadas à manipulação de dados do que ao processamento de texto,
pois os de processamento de texto estão mais bem amadurecidos com base na SGML e podem
proporcionar mais recursos para manipular documentos XML.
Na visão dos autores Moreira et. al. (2007), os trabalhos envolvendo banco de dados e
XML estão apenas sendo iniciados sendo que as demandas para o armazenamento de
informações XML estão aumentando em razão da atual realidade das empresas, que é a troca
de informações entre sistemas e serviços. Segundo o autor os motivos que levam a utilização
de um banco XML são muitos. Administrar grandes volumes de dados XML é um problema
de responsabilidade para a base de dados. XML é um dado qualquer, apenas possui um
formato diferente.
Conforme explicam os autores Moreira et. al. (2007) a primeira grande vantagem é a
integração, pois armazenar dados relacionais e documentos XML juntos, pode-se integrar o
novo dado XML com os dados relacionais existentes. A segunda vantagem é a redução da
complexidade do código, pois as linhas de código são reduzidas fazendo com que o
desempenho geral seja melhor. Também pode ser considerado como vantagem que as
mudanças no esquema do Banco são mais fáceis usando XML e a tecnologia XMLTYPE
(XML nativo).
O autor ainda diz que na transferência de dados, pode ser importante rastrear ou
registrar os dados que estão sendo enviados, de forma de logs. Esses dados retidos podem
precisar futuramente ser consultados. Um repositório que possa ser pesquisado pode ser de
grande ajuda no momento de auditorias de sistemas e dados.
As tarefas que podem ser executadas por um banco de dados XML conforme cita
Graves (2003) podem ser:
31
Armazenar um documento;
Recuperar um documento;
Procurar todos os elementos com um nome de tipo específico;
Procurar todos os elementos com um valor de atributo específico;
Alterar o valor do atributo dos elementos para uma string especificada;
Procurar todos os elementos com um nome de tipo específico que contenham
precisamente um dado de caracteres filho e que seja composto de uma string específica;
Excluir todos os elementos;
Procurar caracteres que contenham uma string específica como uma substring;
Substituir todos os elementos com um nome de tipo especificado, que ocorra
dentro do escopo de um elemento, por outro nome de tipo fornecido;
Nos caminhos da procura anterior, adicionar um atributo especificado ao
elemento com região de dados de caracteres que estiver mais à esquerda; e
Recuperar todos os elementos com um valor de atributo especificado que
também ocorra como um valor de atributo de outro elemento fornecido.
2.4 FERRAMENTAS DE DESENVOLVIMENTO
O protótipo foi construído na linguagem JAVA e o banco de dados utilizado para
armazenar os documentos XML foi o Oracle por ser de grande utilização no mercado, sendo a
escolha de diversas empresas como Banco GMAC, Banco Volksvagen SA, BP Castrol,
BrasilCap, Brasiltelecom, Seguros Unimed, e outras. Crespo (2007) cita que os aplicativos
Oracle ganham concorrências globais, por serem baseados em padrões de mercado e oferecem
melhor qualidade, além de baixo custo.
2.4.1 Bancos de dados Oracle
Chang et. al. (2001) explica que os bancos de dados e o padrão XML oferecem
recursos complementares de armazenamento de dados. Enquanto os bancos de dados
armazenam dados para uma recuperação eficiente, o XML oferece uma fácil troca de dados
entre aplicativos. O autor diz que o Oracle fornece suporte para armazenar documentos XML
aproveitando de ferramentas de administração de banco de dados, como backups.
32
O SGBD da Oracle pode ser utilizado para criar regras sobre os dados e segurança e
para bloquear operações que envolvem a integridade de dados incorporando regras e uma
lógica a esse banco de dados.
Castro (2002) explica que os recursos apresentados pelo Banco de Dados Oracle
permitem capturar a estrutura complexa do XML. Os dados XML podem ser gerenciados no
nível desejado de granularidade e documentos XML dinâmicos podem ser criados.
O banco de dados Oracle foi escolhido por apresentar funcionalidades dos dois
modelos de banco de dados, com suporte a dados XML e também por armazenar documentos
XML na sua forma nativa, utilizando o tipo de dados XMLTYPE. Sendo assim foram criadas
duas bases de dados distintas onde tabelas armazenam o documento no formato relacional e
também armazenam o documento de forma nativa, para que seja efetuado o comparativo dos
modelos.
Na visão de Castro (2002), a Oracle desenvolveu um novo tipo de objeto, o
XMLTYPE, que oferece os mecanismos para armazenar dados XML de forma nativa.
Segundo o autor esse tipo de dados permite aos desenvolvedores utilizar todos os recursos de
um banco de dados relacional e simultaneamente trabalhar com dados XML.
Na visão de Chang et. al. (2001) os benefícios da utilização de dados XMLTYPE são:
A junção da utilização de XML e SQL;
Funções pré-definidas para indexação e navegação;
XMLTYPE utiliza um parser e um processador XML para obter melhor
desempenho e escalabilidade;
Podem ser usados comandos SQL combinado com outros tipos de dados. Pode
ser utilizadas colunas do tipo XMLTYPE para fazer consultas junto com colunas de outros
tipos de dados; e
Podem ser criados índices em determinadas funções para aumentar a
velocidade na avaliação da consulta.
Para armazenar os dados XML, ao criar uma coluna do tipo XMLTYPE, uma coluna
do tipo CLOB é automaticamente criada nas entrelinhas do sistema.
As características de armazenamento desta coluna CLOB podem ser alteradas no
momento da criação da tabela. A principal característica de criar uma tabela ou coluna com
esse tipo de dado é que ela apresenta funções pré-definidas, para a manipulação dos dados
XML, conforme mostra a Tabela 5.
33
Tabela 5. Funções do tipo de dados XMLTYPE
Função Parâmetro Retorno Descrição
createxml() xmlval:
VARCHAR2
XMLTYPE Cria uma instância de um XMLTYPE a
partir de uma string
createxml() xmlval: CLOB XMLTYPE Cria uma instância de um XMLTYPE a
partir de um CLOB
existsnode() xpath: VARCHAR2 NUMBER Dada uma expressão XPATH, checa se
o XPATH aplicado ao documento pode
retornar nós válidos
extract() xpath: VARCHAR2 XMLTYPE Dada uma expressão XPATH, aplica o
XPATH ao documento e retorna o
fragmento como XMLTYPE
isfragment() NUMBER Verifica para saber se o documento é
realmente um fragmento. Retorna um
caso a instância XML contém um
fragmento e zero do contrário
getclobval() CLOB Retorna o documento como um CLOB
getstringval() VARCHAR2 Retorna o valor XML como uma String
getnumberval() NUMBER Retorna o valor numérico para qual o
XMLTYPE aponta
Fonte: Castro (2002)
Chang et. al. (2001) explicam que, além disso, é possível efetuar consultas nos dados
XML. Em tipos de dados XMLTYPE, para que dados possam ser selecionados existem três
maneiras: através de SQL, PL/SQL, ou diretamente na aplicação, utilizando as funções
diretamente existsNode() ou extract(), ou ainda usando operadores de texto para consultar o
conteúdo XML.
2.4.2 Linguagem de Programação
Java foi à linguagem escolhida nesse trabalho de pesquisa devido a sua portabilidade,
onde pode ser executado em qualquer plataforma ou equipamento que possua um
interpretador JAVA. Aliado a isso, Java tem como características: robustez, segurança,
dinamismo, alto desempenho, e facilidade. (JAVA, 2009).
Conforme publicado no site da SUN (2009), a linguagem JAVA é mais simples de
aprender, os programas são escritos com menos códigos e também são melhores escritos.
Além disso, programas podem ser escritos em menos tempo, a dependência de plataforma é
evitada.
34
2.5 SOLUÇÕES SIMILARES
Para esse tópico foram avaliados trabalhos desenvolvidos na área como : “Base de
Dados Relacional ou Nativa? Qual a melhor solução para armazenar Documentos XML?” e
também o trabalho “Um estudo sobre gerenciamento de Dados XML em SGBDs Objetos-
Relacionais e em SGBDs com suporte nativo a XML. Atualmente existem poucos trabalhos
na área, e que possuíam propostas e enfoques diferenciadas da proposta pelo presente
trabalho.
O primeiro trabalho abordou um comparativo entre diferentes formas de
armazenamento de documentos XML no formato relacional e no formato nativo. Para o
formato nativo a autora aborda um modelo de armazenamento do banco de dados Tamino
Server que segundo Mendes (2004), esse modelo de banco de dados está mais ligado a
aplicações Web ou em aplicações que sejam baseadas em XML. Quanto ao modelo relacional
ela afirma que é o modelo mais difundido dentro do mercado de sistemas de informação e por
esse motivo que as empresas em grande parte tentam utilizar essa tecnologia, também por
significar um impacto menor para mudanças.
Mendes (2004) afirma que o SGBD Tamino Server foi o primeiro servidor de dados
XML e é capaz de armazenar diretamente dados XML em sua forma nativa, sem necessidade
de transformação.
Mendes (2004) ressalta algumas características desse SGBD:
Grava e recupera documentos XML;
Permite segurança nos acessos a informações;
Utiliza como linguagem de consulta um subconjunto de XQL;
Processa CSS utilizadas como objetos XML;
Suporta utilização de namespaces;
Implementa DOM;
Utiliza ODBC como interface para base de dados externas;
Suporte a SQL dinâmicos; e
Permite data mapping baseado em padrões XML.
De acordo com Mendes (2004) mesmo com todos esses modelos de armazenamento
não existe uma solução que se possa classificar como a melhor. Segundo a autora a escolha
está ligada ao que a aplicação se propõe e com a condição financeira que a empresa tem
35
disponível para investimentos. Com isso, muitas empresas acabam por utilizar soluções mais
difundidas e aceitas no mercado e com menor custo e impacto.
O segundo trabalho foi referenciado em três diferentes SGBDs o SEDNA, Oracle 10g
e PostegreSQL, analisando o comportamento dos modelos. De acordo com Garcia et. al.
(2008) afirmam que os resultados obtidos foram que tanto o SEDNA quanto o Oracle 10g
apresentaram resultados satisfatórios, porém o autor afirma que no Oracle alguns passos
tiveram ser feitos manualmente, enquanto que o primeiro fez tudo de forma automática e de
modo transparente para o usuário.
Garcia et. al. (2008) ressaltam que dependendo do tipo de XML, o SEDNA é mais
recomendado, devido a sua eficiência e facilidade de tratar documentos sem esquemas. Se o
documento possui estruturas simples e bem definidas o Oracle também pode ser usado com
sucesso. Porém o autor afirma que o PostegreSQL não pode ser considerada uma opção
quando a necessidade por armazenamento XML é requerida, pois segundo o mesmo existem
ainda inconsistências a serem tratadas.
Portanto, como esses trabalhos tiveram abordagens bem específicas, verificou-se a
necessidade de efetuar um estudo comparativo entre diferentes formas de armazenamento
utilizando a ferramenta Oracle.
36
3 DESENVOLVIMENTO
Para esse capítulo serão apresentadas as etapas efetuadas para a criação do protótipo
de armazenamento de documentos XML, e também a análise efetuada sobre os resultados
obtidos.
Para os bancos de dados XML não há uma metodologia consolidada, mas o projeto
tradicional pode ser aplicado. Tanto na metodologia de projeto de banco de dados relacionais
como na de banco de dados XML, foram consideradas as mesmas etapas.
Para um banco de dados relacional e XML a coleta de requisitos é semelhante. A
modelagem, o objetivo do projeto, baseia-se na construção de uma definição para o
documento XML para ser armazenado nos modelos de banco, através de uma DTD ou de um
esquema (XML Schema). A diferença está na utilização de um tipo de dados XMLTYPE, no
caso de banco de dados XML, criado no Oracle.
O protótipo foi construído com a finalidade de armazenar documentos da nota fiscal
eletrônica que de acordo com o site da Secretaria da Fazenda é conceituado como um
documento de existência apenas digital, emitido e armazenado eletronicamente com o intuito
de documentar, para fins fiscais uma operação de circulação de mercadorias ou uma prestação
de serviços, ocorrida entre as partes.
O processo é efetuado da seguinte maneira: a empresa emissora da NF-e (Nota Fiscal
Eletrônica) gerará um arquivo eletrônico contendo as informações fiscais da operação
comercial, o qual deverá ser assinado digitalmente, de maneira a garantir a integridade dos
dados e a autoria do emissor, publicado no site da Secretaria da Fazenda.
A mesma publicação explica que este arquivo eletrônico, que corresponderá a NF-e,
será transmitido pela Internet para a Secretaria da Fazenda de jurisdição do contribuinte que
fará uma pré-validação do arquivo e devolverá um protocolo de recebimento, que é a
autorização de uso, sem o qual não poderá haver trânsito da mercadoria.
Conforme publicado no site da secretaria da Fazenda a NF-e tem como objetivo a
implantação de um modelo nacional de um documento nacional eletrônico que venha
substituir o modelo atual de emissão de notas fiscais em papel, com validade jurídica
garantida pela assinatura digital do remetente, permitindo acompanhamento em tempo real
das operações comerciais pelo Fisco. São esperadas as seguintes vantagens com a emissão de
Nota Fiscal Eletrônica:
37
Redução de custos com impressão e aquisição de papel;
Redução de custos de envio e armazenagem do documento fiscal;
Redução de tempo de parada de caminhões em Postos Fiscais de Fronteira;
Eliminação de digitação de notas fiscais na recepção da mercadoria;
Redução de erros de escrituração devido a erros de digitação de notas fiscais; e
Surgimento de oportunidades na prestação de serviços ligados a NF-e.
Nas próximas seções serão descritos as funcionalidades do protótipo, a análise de
requisitos e os seus respectivos diagramas.
3.1 PROTÓTIPO DE ARMAZENAMENTO DE DOCUMENTOS XML
O protótipo construído carrega e armazena arquivos eletrônicos no formato XML nos
dois modelos de bancos de dados propostos nesse trabalho. Para isso, foram criadas duas
bases distintas, uma no modelo relacional e outra no modelo XML, dando possibilidade ao
operador optar por qual modelo armazenar ou consultar.
Os documentos que o protótipo irá manipular foram coletados da base de testes de
uma grande empresa de alimentos. Estes arquivos XML foram resultantes de testes da
implantação do Projeto NF-e, suas informações são fictícias e não possuem validade fiscal.
Primeiramente foi necessário um estudo das diversas categorias existentes, como Nota
Fiscal de Entrada/Saída, ou ainda, se a nota se refere à cliente, fornecedor ou produtor. Isso é
importante, pois ocasiona uma grande diversidade nos documentos XML, fazendo com que
alguns documentos possuam particularidades, como diferentes tributações que aparecem
somente em alguns modelos de documentos, o que dificultou o processo de modelagem.
Com isso, para que ocorra de maneira adequada, foi feito um estudo das NF-e
existentes na base de testes, determinando assim, quais modelos de NF-e o protótipo pode
manipular, considerando que a categoria escolhida tenha um grande volume de documentos.
Após foram modeladas as bases de dados relacionais e nativas para armazenar esses
documentos XML.
A Figura 11 é um diagrama de atividade que mostra como funciona o protótipo desde
o início onde o operador seleciona os documentos que ele deseja armazenar. A partir de então
será feita a escolha pelo modelo que será armazenado e então os documentos serão gravados
no banco de dados de sua escolha. Se for selecionado o banco de dados XML, os documentos
38
inteiros serão gravados sem nenhuma forma de tratamento, somente será validado o DTD dos
documentos pela aplicação e os documentos inteiros serão armazenados em uma tabela do
tipo XMLTYPE que possuirá uma referência, que é o código do documento, para futuras
consultas, e também o próprio documento no formato XML, inclusive armazenando as
características de hierarquia do documento.
Por outro lado, se o operador optar pelo modelo relacional, primeiramente será
necessário um tratamento nos dados do documento XML, onde os documentos serão
preparados para serem inseridos nas tabelas do modelo relacional.
Figura 11 - Diagrama de atividades para Gravação do Documento
A partir do momento que o operador clicar no botão "Gravar Documentos” a tarefa
será monitorada e os tempos de armazenamento serão gravados de acordo com a escolha do
operador (modelo relacional ou modelo nativo) em uma tabela auxiliar permitindo então
39
efetuar relatórios que irão dar base para o comparativo atendendo um dos critérios
selecionados para o trabalho.
A Figura 12 também é um diagrama de atividade, porém ao invés de mostrar o fluxo
da gravação do documento XML, mostra uma consulta de um documento da Nota Fiscal
Eletrônica. Nessa situação o operador, informa um código da nota fiscal que deseja consultar,
e escolhe de qual modelo de banco ele deseja receber. Da mesma forma que no diagrama
anterior, essa consulta também será monitorada com a finalidade de demonstrar qual modelo é
mais eficiente para recuperar dados das bases de dados. É importante ressaltar que o
documento não será gerado, apenas foi construída uma interface para que as informações
sejam consultadas.
Figura 12 - Diagrama de Atividade para Consulta de Documentos
Para as consultas serão utilizadas ferramentas específicas como a XPath, que permite
efetuar consultas específicas de um elemento apenas do documento. A linguagem XPath
conforme explicado anteriormente, é utilizada para selecionar elementos ou nós. Outra forma
40
de efetuar consultas, no relacional, é utilizando a própria linguagem SQL, efetuando assim a
consulta através das tabelas do modelo relacional.
Com esse estudo foi possível optar por um dos modelos que apresentou melhor
desempenho. Também foi possível mensurar em qual situação cada modelo apresenta
melhores benefícios, o que permite desenvolvedores terem uma maior segurança no momento
de efetuar a escolha de qual modelo de banco escolher em se tratando de documentos que
necessitem de armazenamento de documentos no formato XML.
Os critérios utilizados para a comparação foram:
Performance;
Espaço de armazenamento;
Tempo de armazenamento e recuperação; e
Complexidade de implementação.
Conforme mencionado no item 2.4.2 para o desenvolvimento do protótipo foi utilizada
a linguagem JAVA, por sua facilidade de implementação. A ferramenta NetBeans foi a
selecionada para a implementação por ser livre de licenças e por fornecer suporte a
desenvolvimento JAVA tanto desktop quanto Web.
A API escolhida para manusear o documento XML foi a API DOM. Essa API
funciona da seguinte maneira: primeiramente é declarado um objeto do tipo "Element" que
contém o elemento raiz do documento. Após é criado um objeto do tipo "Nodelist" que é
referenciado para buscar o elemento que é informado dentro da String que irá buscar todos os
elementos filhos. Com isso será feito um laço selecionando todos os filhos por meio da
função "getChildTagValue", buscando o filho do elemento informado na String. A Figura 13
é um exemplo de declaração da API DOM.
41
Figura 13 - API DOM
Ainda sobre a Figura13, o valor da "Tag" filha selecionada na função
"getChildTagValue", alimenta um Array através das funções SET e GET de cada valor do
documento XML, para posteriormente ser gravado no Banco de Dados.
3.1.1 Arquitetura
O protótipo permite carregar um grande volume de documentos XML da Nota Fiscal
eletrônica, de um diretório, e gravar esses documentos no Banco de Dados Oracle utilizando o
modelo de banco de dados escolhido pelo operador . Quando um arquivo é submetido a esse
procedimento, é invocado um método de acordo com a escolha do usuário e o documento é
gravado no modelo escolhido pelo usuário.
Para comunicação com os bancos de dados foram utilizados drivers JDBC
disponibilizados pelo fabricante do SGBD. Estes drivers permitem estabelecer comunicação
com os bancos de dados através de comandos SQL. Para isso foi criada uma classe chamada
"Conecta" que permite que a conexão com o banco seja criada. A Figura 14 mostra o método
que cria essa conexão com o Banco de Dados.
42
Figura 14 - Método para criar conexão
Para o armazenamento dos arquivos no modelo relacional foram criadas as tabelas
NFE, ITENS, e SIGNATURE. Foram necessários esses relacionamentos para conseguir
gravar todos os dados do documento XML. As tabelas 6, 7 e 8 do Apêndice B apresentam
como foram estruturadas essas tabelas no banco. Por outro lado para o modelo nativo foi
criada apenas a tabela XMLTABLE, que possui um campo com código da Nota e um campo
XMLTYPE que contém o conteúdo XML na sua forma nativa. A Tabela 9 do Apêndice B
exemplifica como foi criada a tabela.
3.1.2 Banco de Dados XML Nativo
Conforme explicado no item 2.4.1 o banco de dados escolhido foi o Oracle, por ele
possuir suporte aos modelos propostos por esse trabalho. A versão escolhida para o protótipo
foi Oracle 10g Express, por ser livre de licença e por possuir uma interface Web que permite
inserir comandos SQL para a criação de tabelas e manipulação dos dados inseridos no Banco.
A Figura 15 mostra essa interface com suas principais funções.
Figura 15 - Interface Web Oracle 10g
43
Uma das funcionalidades dessa ferramenta é a possibilidade de criar tabelas sem a
necessidade de utilizar comandos SQL, porém esse recurso não abrange todas as
funcionalidades existentes da ferramenta. No modelo relacional foi possível criar as tabelas
utilizando esse método, sendo apenas necessário informar a chave da tabela, os campos e os
tipos de dados, o que facilitou no processo de criação. A Figura 16 ilustra essa
funcionalidade.
Figura 16 - Criação de tabelas
Por outro lado, para o modelo Nativo, foi utilizada a linguagem SQL, pois foi
necessário declarar um tipo especial de dados, o XMLTYPE como mostra a Figura 17.
44
Figura 17 - Criar tabela XMLTABLE
Quando uma coluna do tipo "SYS"."XMLTYPE" é criada, na verdade é criada uma
coluna CLOB, porém com funções específicas para manipulação de XML, como explicado
anteriormente na Tabela 5.
Assim que a conexão com o banco é estabelecida, já é possível efetuar a inserção de
dados XML. Para isso, se o documento XML possui menos de 4000 caracteres, pode ser
utilizada apenas a função "createxml()" que o documento será armazenado no banco, como
mostra o exemplo da Figura 18.
Figura 18 - Inserção de Dados
Porém se o documento for de maior tamanho, como é o caso do protótipo
desenvolvido essa função não poderá ser utilizada, sendo assim necessário desenvolver uma
função específica para a inserção.
Para o protótipo foi desenvolvido uma função insertXML(), com os parâmetros que
serão as colunas a serem inseridas no banco, como o código da Nota (codigoNF) e a String de
XML(NOTA_DESC). A Figura 19 ilustra essa função.
45
Figura 19 - Função insereXML()
Ainda se tratando da Figura 19, a variável "query" possui o comando que será passado
para o Banco de Dados. A variável "pstmt", é a variável que controla a comunicação com o
banco, e a variável "clob", vai receber o retorno da função "getCLOB()", explicado na Figura
20. Após a função "getClob()" retornar com os valores, o comando SQL é executado, e se
com sucesso a conexão é fechada e o método termina.
A Figura 20 ilustra a função "getClob()", que pega a String de XML e a conexão como
parâmetros, e a partir disso joga em um arquivo temporário CLOB, somente enquanto a
conexão é exigida, ou seja, após executada o arquivo "tempClob" é descartado e é retornado
na variável clob, toda a String XML para ser inserida no Banco de Dados.
46
Figura 20 - Função getClob()
Essa função é necessária para que o arquivo inteiro possa ser carregado na variável do
tipo CLOB passando a conexão como parâmetro, pois como o tamanho do documento era
muito grande, a conexão era perdida e era apresentado um erro na conexão não permitindo a
gravação do documento no banco.
3.2 ANÁLISE DE REQUISITOS
Um requisito de software conforme explica Sommervile (2007, p.79) “são descrições
dos serviços oferecidos pelo sistema e as suas restrições operacionais”.
Conallen (2003), explica ainda que uma especificação de requisitos é um conjunto de
componentes, tais como documentos, registros de bancos de dados, modelos que descrevem
um sistema de software a ser criado sem ambiguidade.
Para mostrar o modo que o protótipo irá funcionar, os próximos tópicos irão mostrar
respectivamente os requisitos funcionais, não funcionais e as regras de negócio em que o
protótipo foi idealizado para suportar o armazenamento de documentos XML nos dois
modelos de bancos de dados.
47
3.2.1 Requisitos Funcionais
Na visão de Sommerville (2007) requisitos funcionais são declarações de serviços que
o sistema deve fornecer como o sistema deve reagir a entradas específicas e como o sistema
deve se comportar em determinadas situações. Também podem determinar o que o sistema
não deve fazer.
Sendo assim, os requisitos funcionais descrevem o funcionamento do protótipo e as
operações que o protótipo irá abranger. Na análise os seguintes requisitos foram encontrados:
RF01: O protótipo deverá permitir gravar, consultar e remover Documentos Fiscais
Eletrônicos; e
RF02: O protótipo deverá permitir emitir relatórios com os tempos de gravação,
tempos de consulta e tempos de remoção.
3.2.2 Requisitos Não Funcionais
Sommerville (2007, p.80) explica que os requisitos não funcionais são “restrições
sobre os serviços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições
sobre o processo de desenvolvimento e padrões”.
Também especificam as características do software, abrangendo a plataforma
utilizada, linguagem de programação, e os bancos de dados utilizados.
Para o protótipo foram identificados os seguintes requisitos não funcionais:
RNF01: o protótipo será desenvolvido para desktop;
RNF02: o protótipo deve ser desenvolvido em linguagem JAVA;
RNF03: o protótipo deve armazenar, consultar e remover documentos XML em banco
de dados Oracle, de forma nativa e também relacional; e
RNF04: o protótipo deve ter telas simples e com descritivos nos botões.
3.2.3 Regras de negócio
As regras de negócio definem as particularidades do funcionamento do protótipo:
RN01: As diversas tarefas efetuadas no protótipo deverão ser efetuadas uma de cada
vez, acompanhando o consumo de memória;
48
3.3 DIAGRAMAS DE CASOS DE USO
Os diagramas de Caso de Uso são os modelos para uma representação das
funcionalidades observáveis do sistema e dos elementos externos a ele. O diagrama de Casos
de Uso molda como a análise de requisitos molda o sistema (BEZERRA, 2002).
Figura 21. Diagrama de Casos de Uso
A Figura 21 ilustra os Casos de Uso pertinentes ao protótipo, sendo que suas
descrições complementares são detalhadas no APÊNDICE A.
3.4 DIAGRAMA DE CLASSES
Nesta seção o Diagrama de Classes de domínio é apresentado. A Figura 22 descreve
as principais classes envolvidas juntamente com o relacionamento com outras classes.
49
Figura 22 - Diagrama de Classe
3.5 TELAS DO PROTÓTIPO
Essa seção tem por objetivo apresentar uma visão geral das telas do protótipo, de
acordo com os casos de usos e os requisitos mostrados nas seções anteriores.
Quando o operador executar o protótipo, será exibida a Tela principal do protótipo,
onde serão apresentadas as funções que o usuário poderá utilizar, conforme mostra a Figura
23.
50
Figura 23. Tela de Controle
3.5.1 Carregar Documentos XML
O operador ao selecionar a primeira opção da Figura 23 "Carregar Documentos
XML", vai acessar a tela apresentada na Figura 24. Nessa tela o operador irá informar o
diretório onde estão os documentos XML que ele deseja gravar no banco. Após, o usuário
deve optar por um dos modelos que ele deseja que seja armazenado, que pode ser no modelo
Relacional ou no modelo Nativo, conforme caso de uso UC 01.01
Figura 24. Tela de Gravação no Banco
51
Em seguida, assim que o operador gravar os dados, os mesmos serão enviados ao
relatório, para depois serem analisados.
3.5.2 Consultar Documentos XML
O protótipo permite ainda efetuar consultas de arquivos que já estejam gravados ao
banco. Para isso deve ser selecionada a segunda opção do menu principal que é a "Consultar
Documentos". A Figura 25 exemplifica como é a tela de consulta, caso de uso UC 01.02.
Figura 25. Tela de consulta ao banco
Essa tela permite efetuar duas formas de pesquisa de documentos. A primeira onde é
informado diretamente o número do documento no campo, e ao clicar no botão "Consultar
Documento", todas as informações referentes aquele documento são carregadas na tela. E a
segunda maneira é a pesquisa por cliente, onde é possível carregar todos os documentos de
um determinado cliente, conforme mostra a Figura 26.
Na pesquisa por cliente, após o usuário escolher o modelo que deseja consultar, deve
ser clicado no botão Consultar. Isso fará com que a lista de clientes que está gravado no banco
seja carregada no "ComboBox". Assim, após escolhido o cliente, é apenas necessário optar
por um cliente e apertar no botão "Carregar Documentos" que a tabela será preenchida com
todos os documentos que aquele cliente possui.
52
Figura 26 - Consulta por Cliente
Ao efetuar a consulta da mesma forma que na gravação é invocado um método para
armazenar nas tabelas dos relatórios os tempos obtidos na consulta.
3.5.3 Remover Documentos XML
A Figura 27 mostra a tela que permite ao operador remover da base de dados o
número de documentos que ele deseja.
Figura 27 - Tela Remoção
Ao clicar no botão "Carregar" serão carregados todos os documentos que estão
armazenados de acordo com o modelo escolhido. Assim após o operador informar a
quantidade de arquivos que deseja remover, sendo esse número menor ou igual a quantidade
de documentos carregados. Essa tarefa também possui monitoração e é disparado a partir do
momento que for clicado no botão "Remover Documentos".
53
3.5.4 Gerar Relatório
O protótipo disponibiliza uma tela de relatório onde é possível verificar todos os
tempos que foram armazenados. É possível identificar a diferença entre os tempos medido em
milisegundos (ms) do modelo nativo e relacional em cada tarefa o que permitiu analisar em
qual atividade cada modelo melhor se destaca, como mostra a Figura 28.
Figura 28 - Relatório de Tempos
3.5.5 Limpa Tabelas
Essa tarefa é utilizada para efetuar a remoção de tempos que não serão mais
necessários para o protótipo. Assim que é selecionada essa opção, todas as tabelas de
monitoria de tempos são limpas e o relatório é reiniciado para novos tempos.
54
3.6 Diagramas de Sequência
Os diagramas de sequência têm por objetivo demonstrar o comportamento e a
interação dos objetos ao longo do tempo, apresentando a sequência das mensagens trocadas e
os objetos que participam da interação, conforme publicado no site Imasters (2005). Nos
próximos itens serão apresentados os diagramas para a gravação e a consulta de documentos.
3.6.1 Gravação de Documentos
Este diagrama representa o processo de armazenamento de novos arquivos ao
protótipo. O diagrama da Figura 29 mostra que o operador carrega um diretório de arquivos, e
após selecionar o modelo desejado os documentos de sua escolha são armazenados.
Figura 29 - Diagrama de Sequência - Gravação
Por último, após a gravação dos documentos, é feito o envio dos tempos de gravação
para o relatório, para poderem ser feitas as devidas análises.
55
3.6.2 Consulta de Documentos
A Figura 30 representa o processo para efetuar uma consulta. O protótipo disponibiliza
duas formas diferentes de efetuar a pesquisa, por número de documento, ou por Razão Social
de Cliente. Se o usuário deseja consultar por número de documento, apenas é necessário
informar o número do documento, que em seguida os dados referentes aquele documento
serão carregados na tela. Caso o operador deseja efetuar a pesquisa por cliente, será
necessário optar por um dos modelos, para que sejam carregados todos os clientes que
possuem documentos cadastrados na ferramenta. Com a escolha concluída, os documentos
referentes àquele cliente selecionado serão trazidos na tela. As duas maneiras possuem
monitoria de performance, e após os documentos serem carregados as informações serão
enviadas ao relatório para posterior consulta.
Figura 30 - Diagrama de Sequência - Consulta
56
3.7 Diagramas ER
O modelo Entidade-relacionamento foi utilizado para implementar a versão do sistema
para o banco de dados Relacional, para atender aos objetivos do presente trabalho em
comparar a performance na manipulação de documentos XML. Na Figura 31 podem ser
observadas as estruturas das tabelas e seus relacionamentos.
Figura 31 - MER Relacional
Para o armazenamento dos tempos foram criadas tabelas somente para esse propósito,
que são utilizados pelos dois modelos de banco de dados, que são as tabelas tempos_grava,
tempos_consultas, tempos_consulta_varios, tempos_remove.
Para o modelo nativo, ao invés de todas essas estruturas, somente foi necessário criar
uma tabela que contém uma chave primária para identificar a NF, e toda a NF-e fica
armazenada inteira preservando sua estrutura, como mostrou a Figura 32.
57
Figura 32 - MER Nativo
3.8 ANÁLISE DOS RESULTADOS
Com a implementação do protótipo concluída, foi iniciada a etapa de testes de
validação. Os testes abordaram o armazenamento, consulta e remoção de arquivos XML.
3.8.1 Armazenamento, Recuperação e Remoção de dados XML
Para efetuar o armazenamento, foi necessário implementar um método através da API
DOM onde todas as informações dos documentos XML são carregadas em variáveis do tipo
"ArrayList", para então serem armazenadas no Banco de dados escolhido. Com isso, a
implementação da carga de dados é a mesma para os dois modelos, limitando as diferenças de
performance ao desempenho do próprio SGBD ou sistema operacional. Para minimizar esta
margem de erro foram realizados 5 testes cada operação (gravação, consulta, e remoção) e os
dados apresentados nas tabelas são resultados da média aritmética dos resultados.
A configuração do computador utilizado é processador Pentium de 2,33GHz, com 6
GB de memória RAM e sistema operacional Windows Seven. Os critérios utilizados para os
testes foram performance, tempo de armazenamento, recuperação e remoção. Para isso foram
inseridas diferentes cargas de documentos para que sejam manipulados no protótipo.
A tabela 6 mostra os tempos obtidos dos testes para o armazenamento de documentos.
Para facilitar a visualização, foi criado o coeficiente de comparação que é o tempo de
gravação dividido pelo tamanho dos arquivos multiplicados por 1000.
58
Tabela 6 - Armazenamento
VOLUME RELACIONAL NATIVO XML VARIAÇÃO
Número de
Arquivos
Tamanho
Dos Arquivos
Média de
Gravação
Coeficiente de
comparação
Média de
Gravação
Coeficiente de
comparação
Comparativo
entre bancos
1 6.690b 1,80ms 0,269058296 5,10ms 0,762331839 183,33%
100 731.291b 33,30ms 0,045535908 52,60ms 0,071927591 57,96%
500 3.194.760b 121,30ms 0,037968423 305,30ms 0,095562734 151,69%
1000 7.534.081b 312,60ms 0,041491457 678,50ms 0,090057434 117,05%
3000 24.763.161b 1604,70ms 0,064801905 3339,00ms 0,13483739 108,08%
4000 30.785.650b 1981,00ms 0,064348162 3936,90ms 0,127881009 98,73%
5500 39.893.190b 2782,20ms 0,069741227 4539,40ms 0,113788845 63,16%
7224 50.775.649b 3686,90ms 0,072611578 6122,80ms 0,120585362 66,07%
TOTAL 174.150.449b 10.535ms 0,74 18.996ms 1,63 105,76%
A coluna variação apresenta a diferença de porcentagem entre os valores obtidos do
tempo de gravação do modelo relacional pelo modelo nativo. É possível observar que todos os
itens obtiveram um percentual positivo para o Banco Relacional, variando de 57,96% ao
gravar 100 arquivos até 183,33% ao gravar apenas um documento. Todos percentuais
comparativos indicam a média de 105,76% de vantagem nesse critério ao banco relacional.
A Tabela 7 ressalta que para a consulta de dados do XML na interface do protótipo, o
desempenho do modelo nativo é inferior, sendo que no modelo relacional é quase que
instantâneo. Também é observada uma diferença de tempos entre documentos, isso é devido o
tamanho do documento, que pode variar, por exemplo, com a quantidade de itens da nota.
Tabela 7 - Consulta por Documento
DOCUMENTO RELACIONAL NATIVO XML VARIAÇÃO
Código Tamanho Média de
Consulta
Coeficiente de
comparação
Média de
Consulta
Coeficiente de
comparação
Comparativo
entre bancos
48893571 6.526b 8,60ms 1,32 86,60 ms 13,27 906,98%
48893574 6.527b 8,40ms 1,29 85,60 ms 13,11 919,05%
48893532 7.062b 10,60ms 1,50 131,20 ms 18,58 1137,74%
48893584 7.414b 9,80ms 1,32 126,20 ms 17,02 1187,76%
48894774 25.250b 19,20ms 0,76 3217,80 ms 127,44 16659,38%
TOTAL 92.146b 56,60ms 6,19 3647,40ms 189,42 5202,72%
É possível visualizar que no menor documento de 6.526 bytes o comparativo entre
bancos ficou em 906,98%, uma diferença notável. Ainda para o maior documento de 25.250
bytes houve uma diferença de 16659,38% de vantagem para o banco relacional.
A diferença entre bancos aumentou 18 vezes enquanto o tamanho do arquivo
aumentou apenas 4 vezes no exemplo do documento de código 48894774.
Para a consulta por clientes na tabela 8 o tempo do modelo nativo é expressivamente
mais lento para efetuar a recuperação de alguma informação ou trecho de um documento
XML. A média da diferença favorece ao banco relacional em 46395,25%.
59
Tabela 8 - Consulta por Clientes
DOCUMENTO RELACIONAL NATIVO XML VARIAÇÃO
CNPJ Número de
Arquivos Tamanho
Tempo de
Consulta
Coeficiente de
comparação
Tempo de
Consulta
Coeficiente de
comparação
Comparativo
entre bancos
64648389034 1 10.511b 2,00ms 0,190 747,80ms 71,14 ms 37290,00%
3927447000107 10 65.011b 2,00 ms 0,031 790,80ms 12,16 ms 39440,00%
8111508000179 34 280.393b 3,00 ms 0,011 871,20ms 3,11 ms 28940,00%
46395000000139 76 510.198b 3,80 ms 0,007 1075,6ms 2,11 ms 28205,26%
680933000762 352 2.129.159b 8,20 ms 0,004 1983,60ms 0,93 ms 24090,24% 47508411005034 604 4.987.732b 11,20 ms 0,002 8300,40ms 1,66 ms 74010,71%
TOTAL 1142 8.017.657 30,20ms 0,245 13769,40ms 91,12ms 46395,24%
Essa diferença entre a consulta de arquivos pode ser explicada porque no modelo
relacional é usada a linguagem original do Oracle (SQL) e no modelo nativo é utilizada uma
API externa (XPath), tornando a recuperação do XML mais lenta.
A tabela 9 mostra os tempos obtidos dos testes do protótipo para a remoção de
documentos.
Tabela 9 – Remoção
VOLUME RELACIONAL NATIVO XML VARIAÇÃO
Número de
Arquivos
Tamanho dos
Arquivos
Tempo de
Remoção
Coeficiente de
comparação
Tempo de
Remoção
Coeficiente de
comparação
Comparativo
entre bancos
1 6.690b 4,00ms 0,598 4,40ms 0,658 10,00%
20 150.022b 7,20ms 0,048 5,00ms 0,033 -30,56%
100 731.291b 15,40ms 0,021 8,20ms 0,011 -46,75%
500 3.194.760b 52,00ms 0,016 22,80ms 0,007 -56,15%
1000 7.534.081b 198,60ms 0,026 53,60ms 0,007 -73,01%
2000 16.315.955b 567,20ms 0,035 93,40ms 0,006 -83,53%
3000 24.763.161b 923,00ms 0,037 167,40ms 0,007 -81,86%
4000 30.785.650b 1202,40ms 0,039 162,60ms 0,005 -86,48%
5500 39.893.190b 2022,80ms 0,051 387,80ms 0,010 -80,83%
7224 50.775.649b 2372,00ms 0,047 618,40ms 0,012 -73,93%
TOTAL 174.150.449b 7364,60ms 0,918 1523,60ms 0,756 -67,01%
De modo geral é perceptível a vantagem de se utilizar o banco nativo na remoção dos
arquivos, com uma média comparativa de 67,01% a mais de performance. É o único critério
que o banco nativo superou o banco relacional e ainda assim não chegou ao dobro de
vantagem.
3.8.2 Complexidade de Implementação e Manutenção
Com o desenvolvimento do projeto podem ser notadas importantes diferenças entre os
modelos. Na fase da modelagem, o banco de dados Relacional exigiu um grande esforço para
mapear de forma adequada, todos os campos do documento XML da Nota fiscal Eletrônica
60
sem haver perda de dados. Para isso foi necessário um estudo das tags que compõem o
documento resultando na criação do diagrama ER explicado no Item 3.7.
No modelo Nativo essa etapa não foi necessária, pois o XML inteiro é armazenado em
apenas uma tabela, não precisando se preocupar com detalhes do documento. Essa economia
de tempo pode ser importante na hora da implantação de um grande projeto, já que a etapa de
modelagem do banco relacional requer uma análise minuciosa para o bom funcionamento da
aplicação. Cabe ao gestor do projeto decidir se para o volume de arquivos previsto compensa
a performance detalhada no item anterior.
Com o estudo da etapa da modelagem, observou-se que os documentos da NF-e apesar
de serem estruturados, apresentam tags que não seguem a regra, ou seja, que podem não
existir em alguns documentos ou assumir diferentes valores. Isso pode ser visto em campos
como IE (Inscrição Estadual), que só possui valor se a nota não tiver destinatário no exterior e
com muita freqüência nas tags de tributação, que de acordo com a carga tributária (ICMS20
ou ICMS40) apresentavam campos totalmente distintos.
Com isso no modelo relacional foi necessário uma série de tratamentos e consistências
para essas tags com valores especiais, pois a biblioteca DOM quando não encontra um
determinado campo gera um "Exception" e não vai para o próximo campo no documento, e já
no modelo nativo o armazenamento é feito sem nenhum tratamento, o documento é
simplesmente gravado no banco.
Para buscar o arquivo XML completo no modelo nativo é preciso apenas um comando
(já que o documento estará armazenado em apenas um campo), e para efetuar a consulta no
modelo relacional, é necessário buscar as informações em diversas tabelas, realizando joins, o
que aumenta a complexidade da implementação.
61
4 CONCLUSÃO
Este estudo apresentou conceitos teóricos e práticos sobre armazenamento de
documentos XML em banco de dados, ainda pouco difundido nos dias atuais. O XML é uma
linguagem cada vez mais utilizada para troca de dados entre sistemas, trazendo uma
necessidade e importância da exploração desse tema.
Com o desenvolvimento do protótipo para o armazenamento de documentos XML, foi
possível obter maiores conhecimentos sobre a manipulação de documentos XML bem como
sobre o comportamento de banco e ferramentas de análises comparativas.
Os resultados mostram que apesar das vantagens na implementação do modelo nativo,
o banco de dados que se mostrou mais eficiente para a maioria das operações ainda foi o
relacional.
A consulta de documentos utilizando a API XPATH, ainda precisa ser aperfeiçoada,
pois ao efetuar uma busca por um campo do XML, essa ferramenta irá percorrer todos os
níveis do XML atrás do campo que se deseja, gerando o mal desempenho da pesquisa.
Para o desenvolvimento do modelo nativo, encontrou-se dificuldades, pois as funções
disponibilizadas pela ferramenta para armazenamento de XML (createXML()), somente
funciona com documentos XML até 4000 caracteres. Dessa forma foi necessário alterar a
forma de gravação, onde foi necessário criar uma função que convertesse os dados de XML
para variáveis do tipo CLOB, para que então fossem gravados no banco XMLTYPE.
Outra dificuldade encontrada na implementação foi a utilização de aspas simples nos
documentos XML para descrever nomes de cidades e razões sociais de clientes, sendo
necessário um trabalho de verificação nos documentos, pois o banco reconhece aspas como
fim de comando o que gera erro na implementação.
Observou-se também que o banco nativo apresentou diversas facilidades como na fase
de modelagem, sendo que essa etapa não foi necessária, pois o documento completo é
armazenado em apenas uma tabela, e já no modelo relacional foi realizado um estudo
aprofundado sobre cada campo do documento XML para que após na implementação, não
ocorresse nenhum erro, e o XML pudesse ser novamente gerado sem perda de informação.
Outro fator importante é que após o desmembramento do XML em colunas e tabelas
no modelo relacional torna-se uma tarefa complexa retornar a estrutura original devido a
hierarquia do documento XML.
62
O objetivo geral do presente trabalho foi alcançado através do desenvolvimento do
protótipo de sistema que possibilitou elaborar o comparativo entre os modelos de Bancos
abordados: Relacional e XML Nativo, sendo que o relacional se destacou na operação de
consulta e gravação de documentos XML, e o modelo nativo obteve um melhor desempenho
na remoção, porém não muito expressivo.
Embora o nativo tenha apresentado uma performance inferior ao esperado, ele ainda
surpreendeu quanto a sua performance em comparação ao relacional, apresentando bom
desempenho. Sugere-se a partir da análise elaborada, que para o desenvolvimento de
ferramentas semelhantes, busque-se avaliar também o escopo do projeto, pois apesar de uma
performance satisfatória na utilização para documentos da NF-e, existem outras
funcionalidades que podem ser exploradas nesse modelo que pode obter melhores resultados.
Assim, conclui-se que o modelo nativo apresenta facilidades que torna o manuseio de
documentos XML mais viáveis, porém ainda não possui maturidade suficiente para que possa
ser considerada solução pelas grandes empresas.
Operações como a consulta precisam ser aperfeiçoadas, desenvolvendo APIS
alternativas, e outras soluções para melhorar o desempenho apresentado. No entanto, uma das
principais vantagens abordadas nesse trabalho, é a facilidade com que o documento XML
nativo pode ser extraído do banco e enviado para outros aplicativos sem necessitar de
complexas consultas a diversas tabelas dos bancos de dados relacionais.
Com isso, empresas podem manter seus bancos relacionais, mas em paralelo a isso
arquivos XML podem ser alimentados com informações da empresa. Se um banco de dados
nativo for utilizado, essa informação pode ser rapidamente disponibilizada com apenas uma
função específica do modelo XML Nativo, gerando uma consulta apenas em uma tabela. Esse
documento estando no formato XML cada empresa pode formatar e editar da forma que
quiser, sendo apenas necessário ser um documento válido, ou seja, que passe pelo Schema
XML criado para a aplicação.
4.1 ANÁLISE DOS RESULTADOS
Portanto torna-se interessante um estudo futuro de outros tipos de documentos com
estruturas menores e menos complexas, para afirmar se em outras estruturas de dados os
bancos se comportam da mesma maneira.
63
Outro comparativo interessante como trabalho futuro seria entre banco de dados
orientado a objetos (SGBDOO) e banco de dados objeto relacional (SGBOR).
Outra sugestão para um comparativo de bancos NFE seria a partir da demanda real de
gravações de notas fiscais numa empresa, visto que variam muito em períodos do dia
(faturamentos) e dias do mês (fechamentos de meta). Testes em paralelo, aonde documentos
fossem emitidos em diversas máquinas e várias operações diferentes ocorrendo ao mesmo
tempo, trariam uma realidade mais próxima.
Também poderia ser considerado como trabalho futuro o desenvolvimento da extração
de arquivos XML no formato de NF-e (como se fosse um relatório) ou XML (arquivo XML)
para comparar a eficiência dos modelos.
Uma dificuldade percebida no comparativo foi a utilização do XPATH, não se
apresentou muito eficiente para recuperar trechos dos arquivos XML, portanto uma sugestão
de estudos seria buscar alternativas que consigam obter melhores resultados para a consulta.
Esse trabalho de conclusão de curso também objetivou ser fonte de pesquisa para
futuros desenvolvimentos que utilizem o XML, trazendo dados comparativos relevantes para
implantação de banco de dados para este formato.
64
5 REFERÊNCIAS BIBLIOGRÁFICAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de
Janeiro: Campus, 2002.
CASTRO, Rogério Guedes. Suporte Nativo a XML no SGBD Oracle 9i. Recife: UFPE –
Centro de Informática, 2002.
CHANG, Ben; SCARDINA, Mark; KARUN, K; KIRITZOV, Stefan; MACKY, Ian;
NOVOSELSKY, Anguel; RAMAKRISHNAN, Niaranjan. Oracle XML: o manual oficial.
Rio de Janeiro: Campus, 2001
CONALLEN, Jim. Desenvolvimento de aplicações Web com UML. Rio de Janeiro:
Campus, 2003.
CRESPO, Rose. Oracle lança banco de dados Oracle 11g. Nova York: Oracle, 2007.
Disponível em: < http://www.oracle.com/global/br/corporate/press/2007_jul/oracle_presenta_
database_11g.html>. Acesso em: 15 ago 2009.
DEITEL, H. M.; NIETO, Lin; SADHU, Praveen. XML: como programar. Porto Alegre:
Bookman, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de bancos de dados: fundamentos e
aplicações. 3ed Rio de Janeiro: LTC Editora, 2002.
GARCIA, Maxiwell Salvador; MENEZES, Anderson Luiz; BOSCARIOLI, Clodis. Um
estudo sobre Gerenciamento de dados XML em SGBDs Objeto-Relacionais e em SGBDs
com suporte nativo a XML. Cascavel: UNIOESTE, 2008.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4ed. São Paulo: Atlas, 2002.
GRAVES, Mark. Projeto de banco de dados com XML. São Paulo: Pearson Education do
Brasil, 2003.
HEUSER,Carlos Alberto. Projeto de banco de dados. 5ed. Porto Alegre: Sagra,2004.
IMASTERS. Diagramas: Sequência e Atividades. Disponível em:
<http://imasters.uol.com.br/artigo/3004/uml/diagramas_seq%C3%BCencia_e_atividades/>
Acesso em: 13.05.2010.
JAVA. Sobre o JAVA 2009. Disponível em: <http://www.java.com/pt_BR/download/faq/
whatis_java.xml>. Acesso em: 15 out de 2009
MATTAR, Fauze Najib. Pesquisa de marketing: metodologia, planejamento. 6ed. São
Paulo: Atlas, 2005.
MENDES, Giovana; Henriques, Pedro Rangel. Base de Dados Relacional ou Nativa? Qual
a melhor solução para armazenar documentos XML?. Braga, 2004
65
MICROSOFT. Treinamento: XML de que se trata? 2009 Disponível em:
http://office.microsoft.com/training/Training.aspx?AssetID=RC011304651046&CTT=6&Ori
gin=RC011304651046. Acesso em: 20 set 2009
MOREIRA, Fagner; ALVES, Lucas; SILVA, Ramon Jocafe; NASCIMENTO, Reginaldo;
CERQUEIRA, Ricardo. Armazenamento de dados XML: Estudo de Caso DB2. Bahia:
UFBA, 2007.
QUIN, Liam. Extensible Markup Language (XML) 2009. Disponível em: <
http://www.w3.org/XML/>. Acesso em: 26 jul 2009.
RAMAKRISHNAN, Raghu. Sistemas de gerenciamento de banco de dados. São Paulo:
Mcgraw-Hill, 2008.
RAY, Erick. Aprendendo XML. Rio de Janeiro: Campus, 2001.
REFSNES, Jan Egil. DTD – XML building blocks. Disponível em:
http://www.xmlfiles.com/dtd/dtd_building.asp. Acesso em: 20 set 2009.
RICHARDSON, J. Roberto. Pesquisa social: métodos e técnicas. 3ed. São Paulo: Atlas,
1999.
ROESCH, Sylvia Maria Azevedo. Projetos de estágio e de pesquisa em administração:
guia para estágios, trabalhos de conclusão, dissertações e estudos de caso. 3ed. São Paulo:
Atlas, 2005.
Secretaria da Fazenda do Brasil, 2009. Disponível em: <http://www.nfe.fazenda.gov.br/
portal/> Acesso em: 03 dez 2009.
SILBERSCHATZ, Abraham. Sistemas de banco de dados. São Paulo, Makron Books, 1999.
SOMMERVILLE, Ian. Engenharia de software, 8ed. Prentice Hall, 2007.
SUN. The Java Technology. Disponível em: http://java.sun.com/docs/books
/tutorial/getStarted/intro/changemylife.html. Acesso em: 12 out 2009.
ZMOGINSKI, Felipe. ABNT contesta aprovação do OPENXML na ISO 2008. Disponível
em: <http://info.abril.com.br/aberto/infonews/052008/30052008-11.shl>. Acesso em: 04 out
2009.
W3SCHOOLS. DTD TUTORIAL 2004. Disponível em: <http://www.w3schools.com/DTD/
default.asp.> Acesso em: 10 out 2009.
XML Technology 2009. Disponível em <http://www.w3org/standards/xml> Acesso em: 10
set 2009.
APÊNDICES
A DESRIÇÃO DOS CASOS DE USO
Neste apêndice são apresentadas detalhadamente as descrições dos casos de uso
mostrados na seção 3.3.
UC 01.01 – Carregar Arquivos
Permite o operador carregar o banco de dados de documentos Nf-e (Figura 24).
Requisito:
RF01: O protótipo deverá permitir criar, consultar e remover uma Nfe;
Condição:
Pré Condição: Ter um documento XML válido no diretório apontado;
Pós Condição: Notas Fiscais importadas no Banco de Dados;
Cenários:
Carregar Arquivos – Principal
1. O operador seleciona no menu a opção para carregar as Nf-e;
2. O protótipo exibe a tela para carregamento das Nf-e;
3. O operador digita as informações a respeito do caminho do diretório a ser carregado;
4. O operador seleciona importar diretório;
5. Todos os documentos são carregados na tabela, com as principais informações;
6. O operador seleciona quais documentos o protótipo deverá gravar;
7. O operador escolhe a forma que deseja gravar as informações;
8. O operador finaliza a operação de criar a solicitação;
9. O protótipo verifica as informações digitadas pelo operador;
10. O protótipo irá armazenar as informações no modelo de banco selecionado pelo usuário;e
11. Os tempos serão armazenados nas tabelas do relatório;
Diretório Inválido – Exceção
Caso o operador não informe o diretório correto ou um diretório que não possui
arquivos XML:
1. Sistema mostra mensagem na tela “Diretório Inválido, verifique”; e
2. Sistema retorna ao passo 3 do cenário Criar Solicitação.
68
Usuário não selecionou arquivos– Exceção
Caso o operador não selecionar nenhum documento na tabela:
1. Protótipo mostra mensagem na tela “Selecione ao menos um documento”; e
2. Protótipo retorna ao passo 6 do cenário Criar Solicitação.
Voltar para Menu principal – Alternativo
Caso o usuário desista de consultar uma Nota Fiscal Eletrônica:
1. Sistema não armazena informações no banco de dados; e
2. Sistema exibe Menu Principal.
UC 01.02 – Consulta Arquivos
Permite o operador carregar efetuar uma consulta de um documento no banco de
dados (Figura 25).
Requisito:
RF01: O protótipo deverá permitir criar, consultar e remover uma Nfe;
Condição:
Pré Condição: Ter um documento XML gravado no banco de dados;
Pós Condição: Retorna informações referentes à nota fiscal pesquisada;
Consultar Arquivos - Principal
1. O operador seleciona no menu a opção para consultar as Nf-e;
2. O protótipo exibe a tela para consulta das Nf-e;
3. O operador digita código da nota fiscal que o operador deseja consultar;
4. O protótipo apresenta a tela de consulta de Nf-e;
5. O operador escolhe a forma que deseja consultar as informações;
6. O operador finaliza a operação de consultar a solicitação;
7. O protótipo verifica as informações digitadas pelo operador; e
8. O protótipo irá apresentar na tela as informações no modelo de banco selecionado pelo
usuário.
Nota Fiscal não encontrada – Exceção
Caso o operador digite um código de Nota Fiscal Inválido:
1. Sistema mostra mensagem na tela “Nota Fiscal não encontrada, verifique”; e
69
2. Sistema retorna ao passo 3 do cenário Criar Solicitação.
Remover Nota Fiscal Eletrônica – Alternativo
Caso o operador resolva apagar uma Nota Fiscal Eletrônica:
1. Operador no passo 3 seleciona remover Nf-e;
2. Operador informa o código da Nota Fiscal Eletrônica;
3. Usuário seleciona o atributo desejado e clica no botão REMOVER;
4. O sistema mostra mensagem “Deseja apagar esse documento?”
5. Usuário confirma a mensagem gerada; e
6. Sistema atualiza informações no banco de dados.
UC 02.03 – Emite Relatórios
Permite ao operador emitir relatórios com os tempos de execução de cada operação
efetuada no banco de dados.
Requisito:
RF02: O protótipo deverá permitir emitir relatórios com os tempos de gravação,
tempos de consulta, e tempos de remoção;
Condição:
Pré-Condição: ter uma nota fiscal cadastrada no banco de dados.
Pós-Condição: Relatórios com informações para estudar os modelos.
Cenários:
Emissão de relatórios – Principal
1. O protótipo exibe a tela para gerar relatório;
2. O protótipo mostra a tela com os documentos cadastrados;
3. O operador informa qual modelo de banco deseja extrair relatórios;
4. O protótipo verifica a seleção do operador;
5. O protótipo gera um relatório e solicita o salvamento do mesmo; e
6. O protótipo retorna a tela inicial.
70
B APÊNDICE DAS ESTRUTURA DAS TABELAS NO BANCO
Tabela 10 - Tabela NFE
Campo Tipo Tamanho Descrição
CODIGONF NUMBER Código da Nota
Chave primária da tabela
CUF NUMBER Código UF do emitente
NATOP VARCHAR2 100 Natureza da Operação
INDPAG NUMBER Descrição do arquivo
MOD NUMBER Modelo do documento
SERIE NUMBER Série do documento
NNF NUMBER Número da Nota Fiscal
DEMI DATE Data de emissão
TPNF NUMBER Tipo Da Nota
CMUNFG NUMBER Código do município
TPIMP NUMBER Tipo de impressão
TPEMI NUMBER Tipo de emissor
CDV NUMBER Dígito verificador da chave de acesso
TPAMB NUMBER Identificação do Ambiente
FINNFE NUMBER Finalidade da emissão da NF-e
PROCEMI NUMBER Processo de emissão da NF-e
VERPROC VARCHAR2 20 Versão do processo de emissão da NF-e
CODEMIT NUMBER CNPJ do emitente
XNOMEEMIT VARCHAR2 100 Razão social ou nome do Emitente
XFANTEMIT VARCHAR2 100 Nome Fantasia do Emitente
XLOGREMIT VARCHAR2 100 Nome Logradouro
NROEMIT VARCHAR2 10 Número
XBAIRROEMIT VARCHAR2 50 Bairro
CMUNEMIT NUMBER Código do município
XMUNEMIT VARCHAR2 50 Descrição do município
UFEMIT VARCHAR2 3 Sigla da UF
CEPEMIT NUMBER Código do CEP
CPAISEMIT NUMBER Código País
XPAISEMIT VARCHAR2 40 Nome do País
FONEEMIT NUMBER Telefone
IEEMIT NUMBER IE
CODIGODEST NUMBER CNPJ destinatário
XNOMEDEST VARCHAR2 100 Razão social ou nome destinatário
XLOGRDEST VARCHAR2 100 Logradouro
CMUNDEST NUMBER Código Município
XMUNDEST VARCHAR2 100 Nome do Município
UFDEST VARCHAR2 3 UF
CEPDEST NUMBER Código do CEP
CPAISDEST NUMBER Código do País
XPAISDEST VARCHAR2 100 Nome do País
71
FONEDEST NUMBER Telefone
IEDEST VARCHAR2 20 IE
VBC NUMBER Base de cálculo do ICMS
VICMS NUMBER Valor total do ICMS
VBCST NUMBER Base de cálculo do ICMS ST
VST NUMBER Valor total do ICMS ST
VPROD NUMBER Valor total dos produtos e serviços
VFRETE NUMBER Valor total do frete
VSEG NUMBER Valor total do seguro
VDESC NUMBER Valor total do desconto
VII NUMBER Valor total do II
VIPI NUMBER Valor total do IPI
VPIS NUMBER Valor do PIS
VCOFINS NUMBER Valor do COFINS
VOUTRO NUMBER Outras despesas acessórias
VNF NUMBER Valor total da NF-e
MODFRETE NUMBER Modalidade do frete
TRANSPCNPJ NUMBER CNPJ ou CPF do transportador
TRANSPXNOME VARCHAR2 100 Razão social ou nome
TRANSPIE VARCHAR2 20 Inscrição Estadual
TRANSPXENDER VARCHAR2 100 Endereço Completo
TRANSPXMUN VARCHAR2 100 Nome do município
TRANSPUF VARCHAR2 3 Sigla da UF
TRANSPVEICPLACA VARCHAR2 8 Placa do veículo
TRANSPVEICUF VARCHAR2 3 Sigla da UF
NFAT NUMBER Número da fatura
FATVORIG NUMBER Valor original da fatura
FATVLIQ NUMBER Valor líquido da fatura
INFADIC VARCHAR2 1000 Grupo de Informações Adicionais
PROTNFE VARCHAR2 100 Tag Raiz do Protocolo de recebimento da
NF-e
INFPROTATT VARCHAR2 100 Informações do protocolo de resposta a ser
assinada
TPAMBPROTNFE NUMBER Identificação do ambiente: 1 - Produção / 2 -
Homologação
VERAPLIC VARCHAR2 40 Versão do aplicativo que processou o lote. A
versão deve iniciar com a sigla da UF.
CHNFE VARCHAR2 100 Chave de acesso da NF-e
DHRECBTO VARCHAR2 100 Data e hora do processamento
NPROT NUMBER Número de protocolo
DIGVAL VARCHAR2 100 Digest Value da NF-e processada
CSTAT NUMBER Código do status de resposta para a NF-e
XMOTIVO VARCHAR2 100 Descrição literal do status da resposta para a
NF-e
72
Tabela 11 - Tabela ITENS
Campo Tipo Tamanho Descrição
CODIGONF NUMBER Código da Nota
Chave primária da tabela
CODIGOITEM NUMBER Código do Item
Chave primária da tabela
CPROD NUMBER Código do produto ou serviço
CEAN NUMBER GTIN (Global trade Item Number) do
produto, antigo código CEAN ou código de
barras
XPROD VARCHAR2 200 Descrição do produto ou serviço
NCM NUMBER Código NCM com 8 dígitos ou 2 dígitos
GENERO NUMBER Gênero do produto
CFOP NUMBER Código fiscal de Operações e prestações
UCOM VARCHAR2 3 Unidade comercial do produto
QCOM NUMBER Quantidade comercial
VUNCOM NUMBER Valor unitário de comercialização
VPROD NUMBER Valor total bruto dos produtos
CEANTRIB NUMBER GTIN (Global trade Item Number) do
produto, antigo código CEAN ou código de
barras
UTRIB VARCHAR2 3 Unidade Tributável
VUNTRIB NUMBER Valor unitário da tributação
ICMS_ORIG NUMBER Origem da mercadoria: 0 - nacional;
1 - estrangeira -
importação direta;
2 - estrangeira -
Adquirida no mercado interno
ICMS_CST NUMBER Tributação do ICMS
ICMS_MODBCE NUMBER Modalidade de determinação da BC do
ICMS
ICMS_VBC NUMBER Valor da BC do ICMS
PICMS NUMBER Alíquota do ICMS
VLICMS NUMBER Valor do ICMS
IPI_CENQ NUMBER Código do Enquadramento Legal do IPI
IPINT_CST NUMBER Código da situação tributária do IPI
PIS_CST NUMBER Código da situação tributária do PIS
PIS_VBC NUMBER Valor da Base de cálculo do PIS
PPIS NUMBER Alíquota do PIS (em percentual)
VPIS NUMBER Valor do PIS
COFINS_CST NUMBER Código da situação tributária da COFINS
COFINS_VBC NUMBER Valor da Base de cálculo da COFINS
PCOFINS NUMBER Alíquota da COFINS (em percentual)
VCOFINS NUMBER Valor da COFINS
INFADPROD VARCHAR2 4000 Informações adicionais do produto
73
Tabela 12 - Tabela SIGNATURE
Campo Tipo Tamanho Descrição
CODIGONF NUMBER Código da Nota
Chave primária da tabela
CANONICALIZATIONMETHOD VARCHAR2 100 Grupo do método de
Canonicalização -
SIGNATUREMETHOD VARHCAR2 100 Grupo do método de Assinatura
REFERENCE VARCHAR2 100 Grupo Reference
DIGESTMETHOD VARCHAR2 100 Grupo do DigestMethod
DIGESTVALUE VARCHAR2 100 Digest Value (Hash SHA-1 –
Base64)
SIGNATUREVALUE VARCHAR2 100 Grupo do signature value
KEYINFO VARCHAR2 4000 Grupo do Key Info
Tabela 13 - Tabela XMLTYPE
Campo Tipo Tamanho Descrição
CODIGONF NUMBER Código da Nota
Chave primária da tabela
NOTA_DESC XMLTYPE 2000