Keli Cristina Manini Susane Schmidt. Uma Ferramenta para Geração de Esquemas XML a partir de Documentos XML

(1)

Uma Ferramenta para Gera¸

c˜

ao de

Esquemas XML a partir de Documentos

XML

Florian´opolis - SC 2006

(2)

Susane Schmidt

Uma Ferramenta para Gera¸

c˜

ao de

Esquemas XML a partir de Documentos

XML

Trabalho apresentado como requisito para gradua¸cão em Bacharelado em Ciências da Computa¸cão

Orientador:

Ronaldo S. Mello

Co-orientador:

Olinto Jos´

e Varela Furtado

Universidade Federal de Santa Catarina - UFSC Departamento de Inform´atica e Estat´ıstica - INE

Florian´opolis - SC 2006

(3)

Lista de Figuras

1 Introdu¸c˜ao p. 5

2 XML - eXtensible Markup Language p. 8

3 Esquemas XML p. 11

3.1 DTD - Document Type Description . . . p. 11 3.2 XML Schema . . . p. 13

4 Gram´aticas p. 16

5 Trabalhos Relacionados p. 19 5.1 XTRACT . . . p. 19 5.2 DataGuides . . . p. 20 5.3 Extra¸c˜ao de esquemas de dados XML: Uma Abordagem de Gram´atica

de Inferˆencia . . . p. 22

6 Processo do Trabalho da Ferramenta p. 28

Anexo A -- Codigos p. 34

(4)

Lista de Figuras

1 Entradas e Sa´ıdas da abordagem BinXs . . . p. 6 2 Exemplo de uma Estrutura XML . . . p. 9 3 Exemplo de elementos em um documento XML . . . p. 9 4 Exemplo de esquema DTD . . . p. 10 5 Exemplo de esquema em XML Schema . . . p. 10 6 Sintaxe e exemplo de uma declara¸cão de atributo em uma DTD . . . . p. 12 7 Sintaxe e exemplo de uma declara¸cão de entidade . . . p. 12 8 Exemplo Deriva¸cão por Extensão . . . p. 14 9 Exemplo de defini¸cão de Elemento Simples na XML Schema . . . p. 14 10 Exemplo de Defini¸cão de Elemento Complexo na XML Schema . . . p. 15 11 Exemplo Elemento Complexo de XML Schema . . . p. 15 12 Exemplo de um subconjunto da gramática portuguesa . . . p. 17 13 Exemplo de um subconjunto da gramática portuguesa segundo outra

nota¸c˜ao . . . p. 17 14 Exemplo de uma Gram´atica Regular . . . p. 17 15 Exemplo documento OEM . . . p. 21 16 Exemplo de documento XML para OEM do Exemplo Locais de

Ali-menta¸c˜ao . . . p. 21 17 Exemplo DataGuide . . . p. 22 18 Exemplo XML Schema para OEM do Exemplo Locais de Alimenta¸c˜ao . p. 23 19 Exemplo de documento XML sobre o Campeonato Europel de Futebol p. 24 20 Exemplo XML Schema Campeonato Europel de Futebol . . . p. 25

(5)

24 Algoritimo Passo 2.2 . . . p. 26 25 Merge de Não Terminais de Estrutura Repetida . . . p. 27 26 Algoritimo Passo 2.3 . . . p. 27 27 Algoritimo Passo 3 . . . p. 27 28 Diagrama da Ferramenta Proposta . . . p. 31 29 Gramática Genérica . . . p. 32 30 Exemplo Primeiro Documento a entrar no Processo . . . p. 32 31 Exemplo Segundo Documento a entrar no Processo . . . p. 32 32 Gramática Espec´ıfica da Primeira Itera¸cão. . . p. 32 33 Gramática Espec´ıfica da Segunda Itera¸cão. . . p. 33 34 XML Schema Gerado com Base no Exemplo. . . p. 33

(6)

1 Introdu¸

c˜

ao

XML (Extensible Markup Language) emergiu como um novo padrão para troca e ma-nipula¸cão de dados descritivos de documentos estruturados. (1) Este fato ocorreu devido a grande quantidade de vantagens que este padrão de linguagem representa: o formato XML é auto-descritivo; documentos XML formam cole¸cões de elementos aninhados hie-rarquicamente; XML é um arquivo texto,não é volumoso, facilita a transferência de dados entre sistemas e a estrutura interna destes documentos pode ser padronizada em esquemas que auxiliam na organiza¸cão, clareza e utiliza¸cão destes. Por estes e demais motivos, a comunidade de pesquisa em bancos de dados tem investido cada vez mais no estudo de XML e novas técnicas e ferramentas para o seu gerenciamento vêm sendo desenvolvidas. A especifica¸cão de um esquema para um documento XML é importante pois permite a valida¸cão de dados XML baseados neste esquema. A partir de um esquema também é poss´ıvel verificar a equivalência dos dados, e então unificar dados de documentos XML com a mesma estrutura. Esta tarefa é importante em sistemas que realizam integra¸cão de dados na Web. Outra vantagem é que a existência de um esquema facilita o mapea-mento de dados XML para esquemas de banco de dados, possibilitando a formula¸cão e o processamento otimizado de consultas.

Apesar destas vantagens, a maioria dos documentos XML dispon´ıveis em computa-dores não possui um esquema associado, e mesmo que o possua, é provável que estes esquemas não sejam idênticos, pois foram definidos por pessoas ou sistemas diferentes. Em fun¸cão disto, este trabalho propõe uma ferramenta que procura solucionar, mesmo que parcialmente, o problema da falta de esquemas, já que a integra¸cão de dados XML tornou-se relevante devido a grande quantidade de dados XML dispon´ıveis na Web atu-almente e para que tal integra¸cão seja facilitada é importante que se conhe¸ca o esquema de cada documento. Além das justificativas citadas anteriormente, essa ferramenta terá aplica¸cão direta na abordagem BInXS (Bottom-Up Integration of XML Schemata). Esta abordagem BInXS foi proposta por (2) e realiza a integra¸cão semântica de esquemas XML com o objetivo de permitir o acesso transparente a dados XML em fontes de dados na

(7)

insere a ferramenta proposta neste trabalho, uma vez que os documentos XML nem sempre são acompanhadas de seus esquemas XML. A figura 1 monstra as entradas e sa´ıdas do processo realizado pelo BinXs. As entradas são documentos XML de fontes de dados da Web e seus esquemas. A sa´ıda é o esqeuma global, a n´ıvel conceitual, que resulta da integra¸cão semântica dos esquemas XML. Este trabalho age como um facilitador para a enrada do processo, gerando esquemas XML para um conjunto de documentos que não possuem um esquema associado.

Figura 1: Entradas e Sa´ıdas da abordagem BinXs

Algumas solu¸cões já foram desenvolvidas no sentido de tentar sanar o problema an-teriormente mencionado (3), (4), (5). Porém, elas geram o esquema a partir de um único documento XML. O objetivo da ferramenta proposta é permitir que o usuário possa infor-mar vários documentos XML de uma mesma autoria ou de uma mesma fonte de dados, e a partir destes documentos seja gerado um esquema XML único e completo. No entanto, um dos maiores problemas na forma¸cão de um esquema XML está relacionado a alcan¸car um esquema que consiga ser completo e compacto, já que estas são caracter´ısticas

(8)

inver-samente proporcionais: esquemas tendem a ser ou muito volumosos ou incompletos. (3) Encontrar um esquema XML que consiga balancear estas duas caracter´ısticas ´e um dos desafios a ser solucionados neste trabalho.

No próximo cap´ıtulo é dada uma breve introdu¸cão a linguagem XML, mostrando um pouco de sua estrutura e funcionalidade. No cap´ıtulo 3 é apresentado o conceito de esquemas XML, com aprofundamento dos tipos de esquemas XML recomendados pela W3C. Para melhor entendimento dos conceitos introduzidos em se¸cões posteriores.

No cap´ıtulo 4, é apresentado o conceito de gramáticas. Já no cap´ıtulo 5, são apresen-tados alguns trabalhos relacionados contribuem com o desenvolvimento deste trabalho. No cap´ıtulo 6 é apresentada a proposta inicial da ferramenta e um cronograma relacio-nando as atividades necessárias para a conclusão do trabalho com o tempo restante para o seu desenvolvimento.

(9)

2 XML - eXtensible Markup

Language

XML( eXtensible Markup Language), padrão popular do consórcio W3C(1), é um formato para troca, representa¸cão e manipula¸cão de documentos estruturados e semi-estruturados (1). Como o próprio nome diz, é uma linguagem de marca¸cão com formato aberto, isto é, o próprio desenvolvedor define as tags que serão utilizadas para construir o documento (6). Pela sua versatilidade e capacidade de extensão, XML é, na verdade, uma meta-linguagem que serve de base para a defini¸cão de novas linguagens de marca¸cão (7). Um documento XML é onde são definidos os dados XML. Estes documentos XML formam uma cole¸cão de elementos tags aninhados hierarquicamente que servem de deli-mitadores de informa¸cão. O conceito de tags é também utilizado na linguagem HTML (Hyper Text Markup Language). Apesar das semelhan¸cas existentes nessas duas lingua-gens, existem diferen¸cas fundamentais. Uma delas é em rela¸cão ao uso das tags, que são pré-definidas em um documento HTML, enquanto possuem valor semântico na lingua-gem XML. Outra diferen¸ca importante está relacionada com a fun¸cão espec´ıfica de cada linguagem. Enquanto a fun¸cão da linguagem HTML está dividida entre estruturar o do-cumento e permitir a apresenta¸cão dos seus dados em um software navegador na internet, XML preocupa-se com a estrutura¸cão da informa¸cão(6).

Cada documento XML possui uma estrutura lógica e f´ısica. A estrutura f´ısica permite a defini¸cão de componentes de documentos chamados entidades, que podem ser nomea-das ou armazenanomea-das separadamente (7). A estrutura lógica é composta de declara¸cões, elementos, comentários, enfim, tudo o que estiver indicado no documento através de marca¸cão(6).

A figura 2 mostra parte da estrutura de um documento XML. Os documentos XML caracterizam-se por apresentar uma estrutura hier´arquica de elementos, come¸cando com um elemento raiz. Os elementos podem ser do tipo simples ou complexo. Elementos complexos cont´em sub-elementos (elementos filhos), que devem estar aninhados com seus

(10)

<NOTA n´umero="1"> <PARA>Professor</PARA> <DE>Keli e Susane</DE>

<CABECALHO>Mensagem</CABECALHO>

<CORPO>N~ao esque¸ca de dar uma boa nota!</CORPO> </NOTA>

Figura 2: Exemplo de uma Estrutura XML

”pais”(8), como mostra a figura 3. Os elementos identificam objetos do documento XML. Por este motivo, o nome dado aos elementos deve estar de acordo com o conteúdo respec-tivo e com a inten¸cão do dom´ınio de aplica¸cão para o qual o ducumento XML é criado. <raiz>

</raiz>

Figura 3: Exemplo de elementos em um documento XML

Para incluir informa¸cões adicionais sobre os elementos são utilizados atributos, que são declarados na tag de abertura do elemento, como pode-se observar na figura 2 que tem o atributo número como uma propriedade do elemento Nota.

Outra caracter´ıstica que determina a forma do documento XML está ligada à no¸cão de esquema, que pode opcionalmente acompanhar um documento XML (3). Um esquema XML tem como fun¸cão descrever a estrutura interna de um documento XML.

Existem dois tipos de esquemas: DTD e XML Schema As figuras 4 e 5 representam respectivamente a estrutura do dado XML da figura 2, descritos através de uma DTD e de um XML Schema. Estas figuras definem um elemento complexo note e sua estrutura que é composta de um atributo e de elementos simples (to, from, heading e body). Os esquemas XML e suas estruturas são detalhados no próximo cap´ıtulo.

¡xsd:element name=’biblioteca’¿ ¡xsd:complexType¿ ¡xsd:element name=’livro’ type

= ’TipoLivro’/¿ ¡/xsd:complexType¿ ¡xsd:complexType name=’TipoLivro’¿ ¡element name=’titulo’ type = ’String’/¿ ¡xsd:complexType¿

(11)

<?xml version-’’1.0’’?> <!DOCTYPE NOTA [

<!ELEMENT NOTA (PARA, DE, CABECALHO, CORPO)> <!ATTLIST NOTA numero PCDATA #IMPLIED>

<!ELEMENT PARA (#PCDATA)> <!ELEMENT DE (#PCDATA)>

<!ELEMENT CABECALHO (#PCDATA)> <!ELEMENT CORPO (#PCDATA)> ]>

Figura 4: Exemplo de esquema DTD

<?xml version=’1.0’ encoding = ’UTF-8’?>

<xsd:schema xmlns:xsd=’http://www.w3.org/2000/10/XMLSchema’> <xsd:complexType>

<xsd:element name=’nota’ type = ’TipoNota’/> </xsd:complexType>

<xsd:attribute name=’numero’ type=’xs:integer’> <xsd:complexType name=’TipoLivro’>

<xsd:sequence>

<xsd: element name = ’PARA’ Type = ’xsd:string’/> <xsd: element name = ’DE’ Type = ’xsd:string’/>

<xsd: element name = ’CABECALHO’ Type = ’xsd:string’/> <xsd: element name = ’CORPO’ Type = ’xsd:string’/> </xsd:sequence>

</xsd:complexType> </xsd:schema>

(12)

3 Esquemas XML

Esquemas XML definem a forma como um documento XML pode ser estruturado. Através do uso destas estruturas, desenvolvedores diferentes podem interagir trocando ou integrando documentos de dados no formato XML, devido ao fato destes diferentes documentos possu´ırem o mesmo esquema. Sistemas de integra¸cão de dados XML, como o BInXS, comentado anteriormente, vêm sendo propostos por pesquisadores e desenvolve-dores para permitirem visões unificadas de dados na Web. Neste contexto, a declara¸cão de esquemas facilita a fusão de tais documentos, uma vez que suas estruturas são conhecidas. Atualmente existem duas recomenta¸cões da W3C para especifica¸cão de esquemas para XML: DTD e XML Schema. Essas recomenda¸cões são descritas a seguir.

3.1 DTD - Document Type Description

Uma DTD define as instru¸cões que são enviadas ao parser XML para o documento que está para ser analisado(6).Essas regras definem o tipo dos elementos que podem ser usados e a hierarquia e granularidade do texto(7).

Uma DTD define o conteúdo de um elemento no formato de expressões regulares (4). Uma DTD é composta por um conjunto de declara¸cões. Cada declara¸cão está de acordo com o formato de marca¸cão0 <! . . . >0 e seus tipos principais são: ELEMENT (defini¸cão de elemento), ATTLIST (defini¸cão de atributo) e ENTITY (defini¸cão de entidade).

Os elementos definem os blocos principais de um documento XML. Eles podem conter texto, outros elementos, ou serem vazios.(8) Na declara¸cão de um elemento é poss´ıvel também definir a quantidade de ocorrências de seus sub-elementos:

• Uma ´unica ocorrˆencia: <!ELEMENT element-name (child-name)>

• M´ınimo de uma ocorrˆencia: <!ELEMENT element-name (child-name+)> • Zero ou mais ocorrˆencias: <!ELEMENT element-name (child-name*)>

(13)

name2) >

Os atributos contêm informa¸cões extras sobre os elementos. Eles estão sempre lo-calizados dentro de uma tag de um elemento e definem sempre um par (nome/valor), como pode ser observado na figura 6 (8). O primeiro parâmetro na declara¸cão é o nome seguido do tipo do atributo, cujos principais tipos são: CDATA (cadeia de caracteres), NMTOKEN (um identificador), NMTOKENS (lista de NMTOKEN), ENTITY (en-tidade),ENTITIES (lista de entidades), ID (id única), IDREF (referêncai ao id de um elemento já existente), IDREFS (lista de IDREF)(7). O parâmetro final especifica um valor que é dado ao atributo quando o autor do documento não informa um valor (7).

Outras restri¸cões que podem ser definidas em um atributo são: #REQUIRED(o atributo é obrigatório), #IMPLIED (o atributo é opcional no elemento) e #FIXED (o valor do atributo é fixo).(8)

<!ATTLIST nome-do-elemento nome-do-atributo tipo-do-atributo valor-padr~ao> Exemplo:

DTD: <!ATTLIST pagamento type (cheque|dinheiro)’’dinheiro’’> XML: <pagamento type=’’cheque’’> ou

Figura 6: Sintaxe e exemplo de uma declara¸c˜ao de atributo em uma DTD

As entidades, demonstradas na figura 7, são variáveis usadas para definir textos co-muns. Uma entidade é utilizada principalmente para evitar a repeti¸cão de textos similares. Isto reduz a carga de trabalho na defini¸cão do esquema, faz com que apare¸cam menos erros e facilita o entendimento da estrutura da DTD. (7)

<!ENTITY nome da entidade ‘‘valor da entidade’’> Exemplo:

DTD: <!ENTITY livro-name ‘‘C´odigo da Vince’’> <!ENTITY autor ‘‘Dan Brown’’>

XML: <livro>&livro-name;&autor;</livro>

(14)

3.2 XML Schema

A recomenda¸cão XML SCHEMA foi aprovada pela W3C em mar¸co de 2001 (1). Surgiu para ser o sucessor de esquemas DTDs e por isso possui todas as funcionalidades desta e ainda caracter´ısticas espec´ıficas que a tornam mais expressiva. Diferente de DTDs, este tipo de esquema é estruturado seguindo o mesmo formato sintático da XML, ou seja, um documento XML Schema é um documento XML. Isto possibilita a utiliza¸cão de parsers XML para fazer a valida¸cão dos esquemas escritos em XML SCHEMA (6).

Outras caracter´ısticas importantes ausentes nas DTDs e presentes nesta recomenda¸cão são: a possibilidade de definir restri¸cões masi detalhadas para valores de dados, o meca-nismo de deriva¸cão e a capacidade de definir tipos de dados para elementos e atributos.

Dentre as caracter´ısticas citadas anteriormente destaca-se o mecanismo de deriva¸cão. Este processo possibilita aos desenvolvedores um controle maior sobre aqueles disponi-bilizados pelo padrão(4),ou seja, o uso de deriva¸cões possibilita ao desenvolvedor criar restri¸cões e incluir/adicionar novos elementos e atributos a defini¸cões de tipos já existen-tes. Dois tipos de deriva¸cão permitidos: por restri¸cão e por extensão.

As deriva¸cões por restri¸cão são declaradas através do uso do elemento < restriction > e possuem propriedades que definem tamanho, padrão, máxima e min´ıma ocorrência, entre outros. Um exemplo de restri¸cão é demonstrado na figura 11: o elemento simples SEXO possui dois valores fixos poss´ıveis: Masculino ou Feminino.

No caso das deriva¸cões por extensão, a declara¸cão é feita através do elemento < complexContent > seguido pelo elemento extension, utilizando-se do atributo base do elemento para indicar o tipo que está sendo estendido. Um exemplo desta deriva¸cão é descrito na figura 8, onde o tipo NovoContato é uma extensão do tipo Contato.

Os elementos declarados em XML SCHEMA podem ser de tipos de dados simples ou complexos. Os primeiros são os elementos formados somente por texto, como podemos observar na figura 9, onde é definido um elemento ’nome’ cujo tipo de dado simples é String. Os complexos são aqueles que possuem outros elementos aninhados dentro de sua estrutura e/ou atributos que determinam as caracter´ısticas dos dados inseridos no documento, como mostra a figura 10. Nesta figura é detectado um elemento complexo EMPREGADO formado pelas tags de elementos simples NOME e SOBRENOME ambas do tipo String, mais um elemento simples salario do tipo float.

(15)

</complexType>

Tipo derivado por extens~ao:

</extension> </complexContent> </complexType>

Figura 8: Exemplo Deriva¸cão por Extensão <xs:element name=ńome´ type=´xs:string´>

Figura 9: Exemplo de defini¸c˜ao de Elemento Simples na XML Schema

de atributos para tipos e elementos do esquema. Devido à existência destes é poss´ıvel de-fini¸cão de diferentes tipos de dados simples (String, Decimal, Integer, Float Boolean, Date e Time). Outra contribui¸cão importante é a possibilidade de definir algumas restri¸cões semelhantes às utilizadas em Bancos de Dados tais como: conteúdo, tamanho, etc.

A figura 11 é um exemplo de um XML Schema com todas as caracter´ısticas presentes nestes esquemas: elementos complexos, restri¸cões, atributos e namespace, dentre outras. Ela mostra o Schema de um documento XML formado por uma tag raiz PESSOAS e seus filhos, compostos de um elemento complexo (linha 4) que possui um elemento simples PESSOA com um atributo maxOccurs= unbounded, indicando que pode haver inúmeras ocorrências deste sub-elemento. Outro elemento complexo é definido dentro de PESSOA. Ele possui dois elementos simples de tipo String. Os atributos de m´ınima e máxima ocorrência podem ser pré-fixados, como definido no elemento NOMEFILHO da linha 10.

(16)

<xs: element name = ´EMPREGADO´> <xs:complexType>

<xs:sequence>

<xs:element name=´NOME´ type=´xs:string´/> < xs:element name=’SOBRENOME’ type=´xs:string´> </xs:sequence >

</xs:complexType> </xs:element>

Figura 10: Exemplo de Defini¸c˜ao de Elemento Complexo na XML Schema

1 <?xml version=’1.0’ encoding=’ISO-8859-1’>

2 <xs:schema xmlns:xs=’http://www.w3.org/2001/XMLSchema 1 elementFormDefault=’qualified’’> 3 <xs: element name = ’PESSOAS’>

4 <xs:complexType> 5 <xs:sequence>

6 <xs:element name=´PESSOA´ maxOccurs=’unbounded’> 7 <xs:complextype>

8 <xs:sequence>

9 < xs:element name=’NOMECOMPLETO’ type=´xs:string´/> 10 < xs:element name=’NOMEFILHO’ type=´xs:string´

minOccurs=’0’ maxOccurs=’5’/> 11 </xs:sequence> 12 </xs:complexType> 13 </xs:element> 14 </xs:sequence > 15 </xs:complexType> 16 <xs:simpleType> 17 <xs:element name=’SEXO’>

18 <xs:restriction base = ’xsd:string’> 19 <xs:enumeration value=’masculino’> 20 <xs:enumeration value=’feminino’> 21 <xs:restriction> 22 </xs:simpleType> 23 </xs:element> 24 </xs:schema>

(17)

4 Gram´

aticas

A palavra gramática e alguns conceitos relacionados serão vistos com freqüência nos próximos cap´ıtulos.Por esta razão, este cap´ıtulo apresenta os conPara melhor entendi-mento deste conceito, é necessário anteriormente explicar outras defini¸cões, como por exemplo, o conceito de linguagem. Uma linguagem, segundo o Dicionário Aurélio ”é o uso da palavra articulada ou escrita como meio de expressão e comunica¸cão entre pes-soas”. Matematicamente falando, é qualquer conjunto ou subconjunto de senten¸cas sobre um alfabeto que podem ser derivadas a partir de um s´ımbolo inicial da gramática que a representa. Um exemplo de linguagem é o XML (eXtensible Markup Language).

O alfabeto é um conjunto finito de s´ımbolos, entidades abstratadas não definidas formalmente, como por exemplo, as letras e os d´ıgitos. A gramática define uma estrutura sobre este alfabeto, de forma a permitir que apenas determinadas combina¸cões sejam válidas, ou seja, sejam consideradas senten¸cas (seqüência finita de s´ımbolos justapostos), definindo assim a linguagem que representa (9).

Formalmente falando, uma gramática é uma quádrupla ordenada G=(V,T,P,S) onde: - V é um conjunto finito de s´ımbolos variáveis ou não-terminais; - T é um conjunto de s´ımbolos terminais disjunto de V; - P é um conjunto finito de pares, demoninados regras de produ¸cão tal que a primeira componente é palavra de (VS

T)+ e a segunda componente ´e palavra de (V S

T)∗; - S ´e um elemento de V denominado - vari´avel inicial ;

As regras de produ¸cão definem as condi¸cões de gera¸cão das palavras da linguagem, como pode-se observar na figura 12.A partir desta figura pode-se retirar a seguinte nota¸cão:

\textbf{<....>} : categoria sint´atica ou gramatical; \textbf{::=} : definido por;

\textbf{|} : alternativa (ou);

(18)

<senten¸ca>::= <sujeito> <predicado>

<substantivo>::= Jo~ao | Maria | cachorro | livro <artigo>::= o | a

<adjetivo>::= pequeno | bom | bela <verbo>::= morde | olha| l^e

Figura 12: Exemplo de um subconjunto da gram´atica portuguesa

Uma forma mais simples de descrever esta gramática é demonstrado na figura 13.Nesta nota¸cão, as categorias são representadas por letras, para facilitar a escrita e ao invés de ::= usa-se ⇒.

X ⇒ SP S ⇒ B — AB — ADB P ⇒ VO B ⇒ João — Maria — cachorro — livro A ⇒ o — a D ⇒ pequeno — bom — bela V ⇒ morde — olha— lê O ⇒ B — AB — ADB Figura 13: Exemplo de um subconjunto da gramática portuguesa segundo outra nota¸cão

Existem 4 tipos de linguagens: linguagem regular (tipo 3), livre de contexto (tipo2), sens´ıveis ao contexto (tipo 1)e enumer´aveis recursivamente (tipo 0).

A linguagem regular é a mais restrita e limitada das linguagens, sendo representada por formalismos de pouca complexidade, grande eficiência e fácil implementa¸cão. Toda linguagem regular é uma gramática livre de contexto, porém as produ¸cões das gramáticas regulares são mais simples do que as produ¸cões das livres de contexto, sendo sempre do tipo linear, como pode ser observado na figura 14.

S ⇒ Aa — Ba A ⇒ Aa — a — B ⇒ Bb — b

Figura 14: Exemplo de uma Gram´atica Regular

A linguagem Simples de Contexto é um pouco mais ampla que a regular, tratando, adequadamente, questões como parênteses balanceados, constru¸cões bloco-estruturadas, entre outras fun¸cões de linguagens de programa¸cão. os algor´ıtmos reconhecedores e ge-radores que implementam esta linguagem são relativamente simples e de boa eficiência. Permitem produ¸cões do tipo S ⇒ aSb e aabb , ou seja, produ¸cões com dois ou mais não-terminais ou terminais juntos .

As linguagens Sens´ıveis ao Contexto abrangem as Livres de Contexto, permitem ainda produ¸cões como SA ⇒ aSb e aabb, com mais de um não-terminal como regra de produ¸cão.

(19)

(20)

5 Trabalhos Relacionados

Este cap´ıtulo apresenta alguns trabalhos relacionados com a extra¸c˜ao de esquemas XML a partir de documentos XML. A partir dos estudos realizados com base nestes trabalhos pretende-se escolher as melhores e mais eficientes t´ecnicas, e estas podem ser ainda adaptadas para o desenvolvimento da ferramenta desejada neste trabalho.

5.1 XTRACT

Este trabalho busca encontrar o DTD perfeito para um documento XML, combinando precisão e intui¸cão, através de uma seqüência de passos que envolvem a procura de padrões nas seqüências de entrada , seguida de uma fatora¸cão dos poss´ıveis candidatos gerados no passo anterior e concluindo com a aplica¸cão do princ´ıpio da Descri¸cão do Tamanho M´ınimo(3).

No primeiro passo, chamado de generaliza¸cão, são empregados algoritmos heur´ısticos para encontrar padrões em cada seqüência de entrada e então substitu´ı-las por expressões regulares apropriadas para produzir candidatos mais gerais. O principal objetivo deste passo é introduzir metacaracteres (∗, +, ?, ...) para produzir sub-expressões que gerem os padrões observados nas seqüências de entrada. Isto é realizado através da descoberta de freqüências e de ocorrências próximas de subseqüências e s´ımbolos em cada seqüência de entrada. Por exemplo, se tivermos como entrada a seqüência abababcababc, este passo vai verificar que a seqüência ab utiliza dois campos e a substituirá pela expressão A1. Como resultado teremos A1cA1c, que finalmente é substitu´ıdo pelo termo ((ab) ∗ c)

O segundo passo, conhecido como fatora¸cão, herda os candidatos a DTD obtidos no passo anterior e tenta torná-los mais concisos através da aplica¸cão de técnicas adaptadas da literatura de otimiza¸cão lógica. A fatora¸cão é usada para tentar obter uma DTD de me-nor tamanho e conseqüentemente de melhor qualidade. Suponha que temos como entrada a seqüência I = ab, abab, ac, ad, bc, bd, bbd, bbbbe e o módulo da generaliza¸cão gerou o se-guinte resultado: G = I ∪ (ab)∗, (a|b)∗, b ∗ d, b ∗ e, que são gramáticas mais genéricas para

(21)

No terceiro e mais importante passo é aplicado o princ´ıpio da Descri¸cão do tamanho M´ınimo. Este mecanismo classifica cada candidato a DTD com base no custo atribu´ıdo a cada DTD. Este custo depende do tamanho da gramática, em bits, que é o responsável para encontrar uma DTD concisa, e do tamanho dos dados, em bits, que define a precisão da candidata.Por exemplo, considere a entrada I = ab, abab, ababab e considere que entre os resultados encontrados estejam (1) ab|abab|ababab e (2) (ab)∗. O cálculo do custo do resultado para 1 é 17 bits, sendo 14 para codificar a DTD (quantidade de caracteres) e +3 para codificar a seqüência de entrada (1 caractere para cada posi¸cão de entrada). Já o cálculo do resultado para 2 é 8 bits, sendo 5 para a codifica¸cão do DTD e 3 para codifica¸cão da seqüência de entrada (necessário para especificar o número de repeti¸cões do termo ab para cada seqüência). (3) Neste caso, a DTD escolhida é o número 2, pois ela conseguiu abranger toda a seqüência de entrada e, ao mesmo tempo, é mais compacta. Segundo o trabalho, os resultados obtidos são satisfatórios, já que sempre consegue-se encontrar uma DTD ótima ou muito próximo disto. Porém, ainda não foram feitos estudos para ampliar o sistema para a capta¸cão de um XML Schema, que é, atualmente, o esquema recomendado pela W3C.

5.2 DataGuides

O conceito DataGuide foi introduzido para aproveitar os benef´ıcios de um esquema para dados semi-estruturados. Os DataGuides são um sumário estrutural de um banco de dados semi-estruturado conciso e exato, que agem como esquemas dinâmicos. Eles são gerados a partir dos dados do banco de dados, são utilizados para formula¸cão de consultas, armazenamento de informa¸cão e também possilitam a otimiza¸cão das consultas.(5)

Este trabalho baseia-se no modelo para dados chamado Object Exchange Model (OEM). Em OEM, cada objeto contém um objeto identificador e um valor, que pode ser atômico ou complexo, um exemplo de OEM pode ser visualizado na figura 15. Por tratar-se de uma representa¸cão de dados semi-estruturada é poss´ıvel obter um documento XML de uma árvore OEM. A figura 16 demonstra um documento XML com os dados apresentados na OEM da figura 15.

(22)

permite realizar opera¸cões em dados semiestruturados utilizando paths. Outra teoria pre-sente neste trabalho é a conversão de autômatos finitos não-determin´ısticos (AFND) para autômatos finitos determin´ısticos (AFD) uma vez que DataGuides podem ser similares estruturalmente a automatos.

Figura 15: Exemplo documento OEM <locais_alimentacao> <restaurante> <nome>Chili’s</nome> <entrada>Salada</entrada> <telefone>3234-0051</telefone> <proprietario>Jos´e da Silva</proprietario> </restaurante> <restaurante>

<nome>Rose & Crown</nome> <entrada>Salada</entrada> <entrada>Sopa<entrada> <gerente>Jos´e da Silva</gerente> </restaurante> <bar>Darbar</bar> </locais_alimentacao>

Figura 16: Exemplo de documento XML para OEM do Exemplo Locais de Alimenta¸c˜ao

DataGuides descrevem um caminho único rotulado com exatamente uma fonte, sem levar em conta o número de vezes que o DataGuide aparece na fonte. Para garantir exa-tidão, um DataGuide não codifica o caminho que não aparece na fonte e para garantir

(23)

Figura 17: Exemplo DataGuide

As caracter´ısticas estruturais e conceituais do DataGuide descritas anteriormente tor-nam esta forma estruturada de representa¸cão de dados uma alternativa para extra¸cão de esquemas XML. Através do relacionamento dos elementos presentes no DataGuide com os elementos de um XML Schema, por exemplo. Os nodos folhas do DataGuide são os elementos simples e os nodos que contem subarvores são os elementos complexos. A figura 18 apresenta o XML Schema do DataGuide demonstrado na figura 17.

</complextype>

(24)

5.3 Extra¸

c˜

ao de esquemas de dados XML: Uma

Abor-dagem de Gram´

atica de Inferˆ

encia

O trabalho de Boris Chidlovskii (4) enfatiza a importância de se possuir uma defini¸cão de esquema para documentos XML e propõe uma alternativa para a extra¸cão deste es-quema através do relacionamento sintático de documentos XML com linguagens Livre de Contexto, ou melhor, uma extensão dessas linguagens.

Através de métodos desenvolvidos para este tipo de gramática e também para as gramáticas regulares, definiu-se um algoritmo baseado em Gramáticas Livre de Contexto para realizar a extra¸cão de esquemas em XML SCHEMA para documentos XML.

No algoritmo sugerido, primeiramente o documento XML é mapeado para um formato de uma linguagem livre de contexto. Posteriormente, métodos de compara¸cão seguidos de métodos de fatora¸cão e consecutiva unifica¸cão de elementos mapeados possibilitam a obten¸cão de uma estrutura, ainda no formato de gramática, que é uma aproxima¸cão do esquema do documento XML. O algoritmo pode ser descrito através dos seguintes passos:

1) Representa¸cão de documentos XML como um conjunto estruturado de dados; 2) Indu¸cão de uma Gramática Livre de Contexto Estendida (GLCE) para o documento XML em questão;

2.1) Cria¸c˜ao do conjunto inicial de n˜ao terminais N;

2.2) Fusão dos elementos não-terminais de N que possuem conteúdo e contexto simi-lares;

2.3) Determina¸c˜ao dos tipos de dados para os terminais em G;

3) Transforma¸c˜ao do resultado da G em uma defini¸c˜ao XML SCHEMA S.

Para um melhor entendimento do algoritmo, é apresentado um exemplo com os re-sultados obtidos a cada passo. A figura 19 mostra um documento XML que contém informa¸cões sobre clubes do futebol europeu e sua situa¸cão dentro dos campeonatos que já disputaram.

A figura 20 mostra como seria o XML Schema correto correspondente ao arquivo XML da figura 19.

A figura 21 representa o resultado do primeiro passo do algoritmo: a representa¸cão de um XML como uma árvore de deriva¸cão da GLC, com todos os não-terminais removidos.

(25)

<ano>1997</ano><classificacao>final</classificacao> ...//5 no total </ChLeague> <UEFA> <ano>1995</ano><classificacao>final</classificacao> ... // 7 no total </UEFA> </time> <time><nome>Manchester United</nome> <ChLeague>

<ano>1999</ano><classificacao>campe~ao</classificacao> ... // 4 no total </ChLeague>

</time>

... // 46 times no total </times>

Figura 19: Exemplo de documento XML sobre o Campeonato Europel de Futebol

Na ´arvore demonstrada na figura 21 temos os nodos internos (circulos) correspondente aos elementos complexos, enquanto as folhas s˜ao as tags ou elementos simples(retangulos).

Na sequência (passo 2) é necessário que se fa¸ca o mapeamento dos elementos presentes no documento XML para a GLCE G.

A correspondente GLCE ´e dada por G = (T,N,D,&,Start) onde T={times, time, nome, ...}, N = {Start, TipoTime, TipoLista}, D = {String, PositiveInteger}, e & contem a regra de produ¸c˜ao demonstrada na figura 22.

O próximo passo do algoritmo (passo 2.1), representado na figura 23, é a gera¸cão do conjunto inicial de não terminais. Para uma melhor visualiza¸cão, associou-se o tipo genérico Any para os elementos simples e um rótulo para cada elemento complexo do documento XML.

Após obtidos os não terminais, é necessário fazer a fusão dos elementos similares (Passo 2.2) - figura 24. O primeiro não terminal a sofrer a fusão é o Start, pois suas produ¸cões possuem ambigüidade com o terminal time. O resultado da fusão continha termos amb´ıguos com terminais ChLeague. Portanto foram fundidos os não-terminais A47 e A49. Estas fusões geraram o seguinte conjunto de produ¸cões:

Observa-se, neste resultado, que os não-terminais A47 e A48 estão repetindo os pares de elementos ano e classificacao, por isso são fundidos. O resultado obtido após as fusões

(26)

</element>

Figura 20: Exemplo XML Schema Campeonato Europel de Futebol

é uma Gramática Livre de Contexto com os não-terminais que geram diferentes produ¸cões (figura 25).

O passo 2.3 analisa as produ¸cões e através de métodos espec´ıficos é obtida a seguinte gramática do documento XML da figura 19:

O último passo do algoritimo é transformar a gramática obtida em um esquema de acordo com as regras definidas em XML Schema. De acordo com a gramática da figura 26 é determinado o XML Schema da figura 27.

O element name é dado pela produ¸cão da Gramatica no não-terminal Inicial (Start − > (time: A1) [46]). O não terminal A1 apontado na produ¸cão citada anteriormente é um elemento complexo pois possui dentro das suas produ¸cões um apontador para mais um não terminal, ou seja, na produ¸cão ”A1 − > nome: String (ChLeague: A4) [0:1] (UEFA:A4) [0:1]” os não terminais A4 indicam que existem elementos inclusos nos ele-mentos formados por A1. O tipo complexo TipoLista é proveniente da produ¸cão ”A4 − > (ano: UnsignedShort classificacao: String) [0:8]”.

(27)

Figura 21: ´Arvore XML - Exemplo Estruturado Start -> times:TipoTime

TipoTime -> (time:TipoTime) [0:500]

TipoTime -> nome:String (ChLeague:TipoLista) [0:1] (UEPA: TipoLista) [0:1] TipoLista -> (ano:PositiveInteger classificacao:String) [1:100]

Figura 22: Gram´atica Livre de Contexto Estendida para XML Times Start -> time:A1 time: A2 time: A3 ... (46 times no total)

A1 -> nome: Any ChLeague: A47 UEFA: A48 A2 -> nome: Any ChLeague: A49

A3 -> nome: Any ...

A47 -> ano: Any classificacao: Any ... // (7 pares ano-classificacao no total) A48 -> ano: Any classificacao: Any ... // (5 pares)

A49 -> ano: Any classificacao: Any ... // (4 pares) ...

Figura 23: Algoritimo Passo 2.1

Start -> time:A1 time:A1 time:A1 ... (46 times no total) A1 -> nome: Any ChLeague: A47 UEFA: A48

A1 -> nome: Any ChLeague: A47 A1 -> nome: Any

A47 -> ano: Any classificacao: Any ... // (7 pares) A48 -> ano: Any classificacao: Any ... // (5 pares) A47 -> ano: Any classificacao: Any ... // (4 pares) ...

(28)

Start -> (time:A1) [46]

A1 -> nome: Any ChLeague: A47 UEFA: A47 | nome: Any ChLeague: A47 | ...

A47 -> (ano: Any classificacao: Any) [7] | ano: Any classificacao: Any)[5] |...

Figura 25: Merge de N˜ao Terminais de Estrutura Repetida

Start -> (time: A1) [46]

A1 -> nome: String (ChLeague: A4) [0:1] (UEFA:A4) [0:1] A4 -> (ano: UnsignedShort classificacao: String) [0:8]

Figura 26: Algoritimo Passo 2.3

</element>

(29)

6 Processo do Trabalho da

Ferramenta

A idéia inicial para o desenvolvimento da ferramenta desejada baseia-se no princ´ıpio de que XML é uma linguagem finita e, conseqüentemente, um documento XML finito. Em fun¸cão disto, é poss´ıvel obter, a partir de sua estrutura, uma gramática. Devido a este conceito, a ferramenta utiliza-se de gramáticas para a obten¸cão dos seus objetivos.

A solu¸cão proposta é definida em 4 etapas, que são: 1. Análise de Entrada; 2. Defini¸cão de Estruturas; 2.1 Análise através de uma gramática genérica; 2.2 Montagem da Tabela de S´ımbolos; 3. Defini¸cão e Valida¸cão da Gramática Final; 4. Conversão. Estas etapas podem ser melhor visualizadas através da figura 28. A primeira etapa recebe como entrada uma fonte de dados XML. Porém, esta fonte pode ser muito extensa por conter muitos documentos XML,tornando o processo muito lento. Portanto, nesta fase é realizado, através de métodos probabilisticos, a defini¸cão de uma amostra que varia de acordo com a quantidadde de documentos da fonte de dados XML. O processo de escolha dos documentos que pertencem ao conjunto analisado é randômico. O primeiro elemento selecionado passará para a fase seguinte, os demais vão direto para a fase de valida¸cão.

A segunda etapa é a etapa em que é analisada a estrutura do documento. Este será validado através de uma gramática genérica geradora de documentos XML que pode ser visualizada na figura 29.Esta gramática, que é utilizada para descobrir se o documento XML é bem-formado, ainda está sendo desenvolvida.A partir desta gramática será gerada a tabela de s´ımbolos. Esta tabela é a estrutura que guarda as informa¸cões essenciais sobre cada identificador reconhecido no documento. Estas informa¸cões identificam o tipo dos elementos, atributos, entre outras caracter´ısticas. As informa¸cões armazenadas na tabela de s´ımbolos serão de extrema importância para o próximo passo.

A terceira fase é responsável por, baseada nas informa¸cões geradas na fase anterior, definir a gramática espec´ıfica do documento XML. Esta gramática dá informa¸cões de

(30)

hierarquia e complementa com todas as informa¸cões necessárias para a montagem do esquema. Sua estrutura varia de acordo com o tipo do documento. Após criada pela primeira vez, servirá de teste para os próximos documentos XML. Ao selecionar o próximo documento, este tem sua estrutura comparada à estrutura da gramática gerada. Se estiver válido e houver mais documentos XML para serem processados, mantém-se a gramática gerada anteriormente e processa-se o próximo documento XML. Se forem encontradas diferen¸cas, este documento é enviado para a etapa 2, onde passará pela valida¸cão através da gramática genérica e então serão acrescentas as diferen¸cas encontradas em rela¸cão aos documentos anteriores. Isto faz com que a gramática espec´ıfica gerada seja incrementada, já de volta a etapa 3. Esta gramática atualizada passa a ser a gramática utilizada nos testes de compara¸cão.

Após ser percorrida toda a amostra de documentos, a gramática gerada será a gramática final, representativa do esquema de todos os documentos analisados. Esta, então, passará por um processo de conversão para a linguagem XML Schema, atual recomenda¸cão da W3C para especifica¸cões XML. Além disso, essa é a linguagem de esquema para XML adotada como entrada pelo BInXS.Vale lembrar que a gramática gerada deve ser guardada para eventos futuros, ou seja, ela deve ser armazenada e o foramto de armazenamento está sendo decidido.

O último passo é fazer a conversão da gramática gerada em um esquema XSD (XML Schema Definition) baseado na tabela de Simbolos resultante e na gramática espec´ıfica final.

Para exemplificar o funcionamento da ferramenta sup˜oe-se que os documentos da figura 30 e 31 fazem parte da amostra selecionada na primeira etapa do processo,sendo o documento da figura 30, o primeiro documento de entrada.

Após o primeiro documento ser validado pela Gramática Genérica da figura 29 é gerada a tabela de s´ımbolos 2 que contém informa¸cões relevantes para a cria¸cão da Gramática Espec´ıfica e o esquema do documento.Nesta tabela, que ainda está sendo desenvolvida, as abrevia¸cões LE, LA,LP e LF significam respectivamente: Lista de Ele-mentos, Lista de Atributos, Lista de Pais e Lista de Filhos.

A partir da tabela de s´ımbolos (tabela2) é estabelecida uma gramática espec´ıfica que serve de compara¸cão para os próximos documentos da amostra. A gramática da figura 32 representa o resultado da etapa de Defini¸cão de Estruturas.

(31)

2 <livro> complexo LP(1) LF(3,4) LA() 1-1 −− 3 <titulo> simples LP(2) LA() 1-1 String 4 <autor> complexo LP(2) LF(5) LA() 1-1 −− 5 <nome> simples LP(4) LA() 1-1 String 6 <edicao> simples LP(2) LA() 1-1 String

Tabela 2: Tabela de Simbolos `a partir do documento 1.

consiste em conferir se este documento é validado pela gramática da figura 32. Caso sejam encontradas divergências significa que esta gramática precisa ser incrementada. Neste exemplo observa-se diferen¸cas fazendo-se necessária a reformula¸cão da tabela de s´ımbolos(tabela 4) e então, da gramática espec´ıfica. As altera¸cões estão destacadas em negrito.

Id Elemento Categoria LE LA Cardinalidade Tipo 1 <biblioteca> raiz LF(2) LA() 1-1 −− 2 <livro> complexo LP(1) LF(3,4) LA() 1-1 −− 3 <titulo> simples LP(2) LA() 1-1 String 4 <autor> complexo LP(2) LF(5) LA() 1-1 −− 5 <nome> simples LP(4) LA() 1-1 String 6 <edicao> simples LP(2) LA() 0-1 String 7 <e-mail> simples LP(4) LA() 1-1 String

As mudan¸cas ocorridas nesta etapa são responsaveis pelos acréscimos de produ¸cões na gramática espec´ıfica visualizada na figura 33.

Este procedimento de incremento da tabela e da gramática é realizado até que todos os documentos da amostra sejam verificados.

A etapa final toma os dados presentes na tabela de s´ımbolos e na gramática espec´ıfica resultantes e cria o esquema aproximado referente aos documentos XML da fonte de dados em questão. A figura 34 demonstra o XML Schema gerado à partir dos documentos analisados (figura 30 e 31).

A proposta de funcionamento sugerida para a ferramenta ainda não é definitiva. Mu-dan¸cas na solu¸cão proposta podem ocorrer durante o desenvolvimento da ferramenta. A tabela abaixo apresenta as atividades futuras a serem realizadas até o término do TCC.

(32)

Tabela 5: Cronograma de Atividades Futuras

Jan/Mar Abr/Mai Jun/Ago Ago/Ago

Conclusão da Proposta Implementa¸cão Testes e Experimentos Reda¸cão do TCC

(33)

E-> string | integer | ...

Figura 29: Gram´atica Gen´erica

<?xml version="1.0" encoding= "US-ASCII"?> <biblioteca>

<livro>

<titulo> Onze minutos </titulo> <autor>

<nome> Paulo Coelho </nome> </autor>

<edicao> Segunda </edicao> </livro>

</biblioteca>

Figura 30: Exemplo Primeiro Documento a entrar no Processo

<?xml version="1.0" encoding= "US-ASCII"?> <biblioteca>

<livro>

<titulo> A Herdeira </titulo> <autor>

<nome> Sidney Sheldon </nome>

<e-mail> sheldon@gmail.com </e-mail> </autor>

</livro> </biblioteca>

Figura 31: Exemplo Segundo Documento a entrar no Processo

R -> <biblioteca>L</biblioteca> L -> <livro>A</livro>

A -> <autor>B</autor> | <titulo>T</titulo> | <edicao>T</edicao> | AA B -> <nome>T</nome>

T-> String

(34)

R -> <biblioteca>L</biblioteca> L -> <livro>A</livro>

A -> <autor>B</autor> | <titulo>T</titulo> | <edicao>T</edicao> | AA B -> <nome>T</nome> | <e-mail>T</e-mail>

T-> String

Figura 33: Gram´atica Espec´ıfica da Segunda Itera¸c˜ao.

<?xml version="1.0" encoding= "US-ASCII"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name=’biblioteca’>

<xsd:complexType>

<xsd:element name=’livro’ type = ’TipoLivro’/> </xsd:complexType>

<xsd:complexType name=’TipoLivro’>

<xsd:element name=’autor’ type = ’TipoAutor’/> </xsd:complexType>

<xsd:complexType name=’TipoAutor’>

<xsd:element name=’nome’ type = ’String’/> <xsd:element name=’e-mail’ type = ’String’/> </xsd:complexType>

</xsd:element> </xsd:schema>

(35)

(36)

Referˆ

encias

1 W3C. World Wide Web Consortium. Acesso em 10/2006. Dispon´ıvel em: <www.w3c.org>.

2 MELLO, R. dos S. Binxs. 2003.

3 GAROFALAKIS ARISTIDES GIONIS, R. R. S. S. K. S. M. Xtract: A system for extracting document type descriptors from xml documents.

4 CHILDLOVSKII, B. Schema extraction from xml data: A grammatical inference approach.

5 GOLDMAN, J. W. R. Dataguides: Enabling query formulation and optimization in semistructed databases.

6 JR., J. R. T. XML Schema. [S.l.]: Visual Books Ltda, 2002. 7 BRADLEY, N. The xml schema companion. 2003.

8 W3SCHOOL. w3cschool.com. Acesso em 10/2006. Dispon´ıvel em: <www.w3cschool-.com>.

9 MENEZES, P. B. Linguagens Formais e Autˆomatos. [S.l.]: Editora Sagra Luzzatto, 2002.