UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 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

2 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

3 SUMÁRIO LISTA DE ABREVIATURAS... iv LISTA DE FIGURAS... v LISTA DE TABELAS... vi RESUMO... vii ABSTRACT... viii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA LINGUAGEM XML Surgimento da linguagem XML Definição de tipo de documento (DTD) Esquema XML Corpo do documento Razões para utilizar XML FORMAS DE ARMAZENAMENTO DE DADOS XML BANCO DE DADOS Banco de dados relacionais com suporte XML Armazenamento com granulação pequena Armazenamento com granulação grande Banco de dados XML Nativo FERRAMENTAS DE DESENVOLVIMENTO Bancos de dados Oracle Linguagem de Programação SOLUÇÕES SIMILARES DESENVOLVIMENTO PROTÓTIPO DE ARMAZENAMENTO DE DOCUMENTOS XML Arquitetura ii

4 3.1.2 Banco de Dados XML Nativo ANÁLISE DE REQUISITOS Requisitos Funcionais Requisitos Não Funcionais Regras de negócio DIAGRAMAS DE CASOS DE USO DIAGRAMA DE CLASSES TELAS DO PROTÓTIPO Carregar Documentos XML Consultar Documentos XML Remover Documentos XML Gerar Relatório Limpa Tabelas DIAGRAMAS DE SEQUÊNCIA Gravação de Documentos Consulta de Documentos DIAGRAMAS ER ANÁLISE DOS RESULTADOS Armazenamento, Recuperação e Remoção de dados XML Complexidade de Implementação e Manutenção CONCLUSÃO ANÁLISE DOS RESULTADOS REFERÊNCIAS BIBLIOGRÁFICAS iii

5 LISTA DE ABREVIATURAS AJAX API B2B CSS DBA DTD DOM ER GML HTML ISO ODF PDF RSS SAX SGBD SGBDOO SGBDOR SGML TCC UML UNIVALI URI XSDL XSLT XML W3C Asynchronous JavaScript and XML Application Programming Interfaces Business-to-Business Cascading Style Sheet Database Administrator Document Type Definition Document Object Model Entidade-Relacionamento Generalized Markup Language Hyper Text Markup Language International Organization for Standardization Open Document Format Portable Document Format Really Simple Syndication Simple API for XML Sistema Gerenciador de Banco de Dados Sistema Gerenciador de Banco de Dados Orientado a Objeto Sistema Gerenciador de Banco de Dados Objeto Relacional Standard Generalized Markup Language Trabalho de Conclusão de Curso Unified Modeling language Universidade do Vale do Itajaí Uniform Resource Identifiers Linguagem de definição do Esquema XML Extensible Stylesheet Language Transformation extensible Markup Language WWW Consortium iv

6 LISTA DE FIGURAS Figura 1. Exemplo XML... 7 Figura 2. Exemplo documento XML com DTD interno Figura 3. Exemplo XML Schema Figura 4. Documento XML Figura 5. NAMESPACES Figura 6. XPOINTER Figura 7. Os três níveis de abstração dos dados Figura 8. Esquema lógico no modelo de dados relacional usando a granulação pequena Figura 9. Esquema Lógico normalizado Figura 10. Esquema Lógico normalizado do banco relacional com granulação pequena para armazenamento XML Figura 11 - Diagrama de atividades para Gravação do Documento Figura 12 - Diagrama de Atividade para Consulta de Documentos Figura 13 - API DOM Figura 14 - Método para criar conexão Figura 15 - Interface Web Oracle 10g Figura 16 - Criação de tabelas Figura 17 - Criar tabela XMLTABLE Figura 18 - Inserção de Dados Figura 19 - Função inserexml() Figura 20 - Função getclob() Figura 21. Diagrama de Casos de Uso Figura 22 - Diagrama de Classe Figura 23. Tela de Controle Figura 24. Tela de Gravação no Banco Figura 25. Tela de consulta ao banco Figura 26 - Consulta por Cliente Figura 27 - Tela Remoção Figura 28 - Relatório de Tempos Figura 29 - Diagrama de Sequência - Gravação Figura 30 - Diagrama de Sequência - Consulta Figura 31 - MER Relacional Figura 32 - MER Nativo v

7 LISTA DE TABELAS Tabela 1. Especificação do Objeto Tabela 2. Mapeamento do documento XML para campos do objeto Tabela 3. Especificação do Objeto Tabela 4. Exemplo de instância da relação da tabela cidade Tabela 5. Funções do tipo de dados XMLTYPE Tabela 6 - Armazenamento Tabela 7 - Consulta por Documento Tabela 8 - Consulta por Clientes Tabela 9 Remoção Tabela 10 - Tabela NFE Tabela 11 - Tabela ITENS Tabela 12 - Tabela SIGNATURE Tabela 13 - Tabela XMLTYPE vi

8 RESUMO PAIVA FILHO, Daniel. Estudo comparativo entre banco de dados relacional e XML nativo. Itajaí, 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í, 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. vii

9 ABSTRACT PAIVA FILHO, Daniel. Comparative study of relational database and xml native. Itajaí, Completion of course work (Bachelor's Degree in Computer Science), Science Technology Center of the Earth and Sea, University of Vale do Itajaí, 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. viii

10 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.

11 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 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 2

12 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 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 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. 3

13 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 4

14 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. 5

15 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 6

16 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 7

17 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 e 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 8

18 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 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 9

19 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, 10

20 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 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 11

21 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) 12

22 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 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 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. 13

23 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 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). 14

24 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 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 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) 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 15

25 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) 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. 16

26 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 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 17

27 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) 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 18

28 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). 19

29 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. 20

30 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. 21

31 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. 22

32 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, 23

33 pois é quem melhor conhece a organização. Portanto são modelos usados para descrever a organização, conforme explica Heuser (2004) Banco de dados relacionais com suporte XML Com base em Ramakrishnan (2008), o modelo relacional foi proposto em 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 24

34 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 Videira SC Itajaí SC São Paulo SP Curitiba PR 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. 25

35 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 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) 26

36 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. 27

37 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. 28

38 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) 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. 29

39 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: 30

40 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 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. 31

41 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. 32

42 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 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. 33

43 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 34

44 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. 35

45 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: 36

46 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 37

47 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 38

48 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 39

49 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 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. 40

50 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 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. 41

51 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 Banco de Dados XML Nativo Conforme explicado no item 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 42

52 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

53 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. 44

54 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. 45

55 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. 46

56 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 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 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; 47

57 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. 48

58 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

59 Figura 23. Tela de Controle 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 Figura 24. Tela de Gravação no Banco 50

60 Em seguida, assim que o operador gravar os dados, os mesmos serão enviados ao relatório, para depois serem analisados 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 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. 51

61 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 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". 52

62 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 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. 53

63 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 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. 54

64 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 55

65 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

66 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 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