KR20060032463A

KR20060032463A - 상이한 구조의 대용량 ＸＭＬ 데이터 검색을 위한 ＸＭＬＤＢ 구축방법과 ＸＱｕｅｒｙ 엔진 시스템 및 그 방법

Info

Publication number: KR20060032463A
Application number: KR1020040081416A
Authority: KR
Inventors: 이성진
Original assignee: 정보통신연구진흥원; (주)파슨텍
Priority date: 2004-10-12
Filing date: 2004-10-12
Publication date: 2006-04-17

Abstract

본 발명은 다양한 구조 형식의 XML 문서를 고정된 XML DB 테이블에 저장하고, XQuery 명령을 통하여 XML DB에 접근하는 XML 엔진 시스템 및 그 수행방법에 관한 것이다.

본 발명의 XML 엔진 시스템에 따르면, XML 파서 명령, XQuery 명령 또는 일반 SQL 명령을 전달하고 그 처리결과를 리턴받는 XML 엔진; XML 엔진으로부터 XML 파서 명령을 제공받아 파서 실행을 제어하고, XQuery 명령을 SQL 명령으로 변환하고, SQL 명령으로 XML DB를 검색하여 받은 결과를 결과 XML 문서로 변환하여 XML 엔진으로 리턴하는 XML 어댑터; XML 어댑터에 의해 실행되고 XML 엔진이 지정하는 입력 XML 문서를 파싱하여 스키마정보와 엘리먼트정보를 생성하는 XML 파서; 및 XML 어댑터로부터 스키마정보와 엘리먼트정보의 데이터를 전달받아 저장하고, SQL 명령의 실행에 의하여 검색된 결과를 XML 어댑터로 리턴하는 XML DB를 포함하여 구성된다.

본 발명에 따르면, XML 문서 파일로부터 스키마정보 및 데이터정보를 추출하여 XML DB에 저장시킴으로써 대용량의 XML 문서가 저장되더라도 바르고 효율적인 DB 접근성을 제공하며, 자연어에 가까운 XQuery 질의어를 SQL 명령으로 자동 변환함으로써 DB에 관하여 전문적인 지식이 없는 사용자라도 XQuery 명령을 통하여 원하는 XML 문서의 정보를 쉽고 빠르게 이용할 수 있다.

XML, 문서, 스키마, 엘리먼트, RDBMS, XQuery, SQL

Description

상이한 구조의 대용량 ＸＭＬ 데이터 검색을 위한 ＸＭＬＤＢ 구축방법과 ＸＱｕｅｒｙ 엔진 시스템 및 그 방법{Method for constructing XML DB and System and its method for XQuery engine in searching massive XML Data with different schema}

도 1은 XML DB 구축방법의 개략적 기능도.

도 2는 예제 XML 문서를 나타내는 예시도.

도 3은 도 2의 XML 문서를 파싱(parsing) 후 엘리먼트들의 시작번호(start position)와 종료번호(end position)를 부여하는 방법을 나타낸 도면

도 4는 XML DB 구축방법의 전체 순서도

도 5는 XML SAX를 실행하여 스키마정보파일 및 엘리먼트정보파일의 생성 과정에 대한 상세 순서도.

도 6은 도2의 XML문서를 도5에서 실행한 후 생성된 스키마정보파일의 데이터 예시도.

도 7은 도2의 XML문서를 도5에서 실행한 후 생성된 엘리먼트정보파일의 데이터 예시도.

도 8은 도 6과 도 7의 text 파일을 XML DB에 저장하는 table 구조도.

도 9는 본 발명에 따른 XML 엔진 시스템의 개략적 기능도.

도 10은 본 발명에 따른 XML 엔진 시스템의 개략적 구성도.

도 11은 본 발명에 따른 XML 엔진 시스템의 수행방법에 대한 개략적 기능도.

도 12는 본 발명에 따른 XML 엔진 시스템의 수행방법에 대한 전체 순서도.

도 13은 본 발명에 따른 XQuery 명령 변환단계의 상세 순서도.

도 14는 본 발명에 따른 어댑터 명령어 생성 및 전달단계의 상세 순서도.

* 도면의 주요 부분에 대한 부호의 설명 *

1 : XML 엔진 시스템 2 : XML 엔진

3 : XML 어댑터 4 : XML 파서

5 : XML DB 21 : 스캐너부

22 : 파서부 23 : 명령어 생성부

31 : 파서 실행부 32 : XQuery 변환부

33 : SQL 실행부 34 : 결과 XML 문서 생성부

35 : 드라이버 관리부 36 : 결과 리턴부

본 발명은 다양한 구조의 대용량 XML 데이터를 효율적으로 관리하고 다양한 질의를 수행할 수 있도록 XML 문서를 고정된 데이터베이스 테이블에 저장 관리하는 방법과 이를 수행하도록 프로그램된 소프트웨어에 관한 것이다.

더욱 상세히 설명하면, XML 문서를 파싱한 후, 각각의 엘리먼트 및 속성, 값 에 대하여 레벨정보(element depth), 순서정보(element sequence), 속성정보(element attribute), 이름(element name), 부모정보 (parent element), 시작번호(start position), 종료번호(end position)를 추출하는 방법과 이를 text 파일로 생성 후 고정된 2개의 데이터베이스 테이블에 저장하는 방법 및 수행 프로그램에 관한 것이다.

최근 인터넷의 발전과 정보 양의 급증으로 인하여, 인터넷상의 효율적인 정보 교환을 위하여 차세대 웹문서의 표준인 XML(eXtensible Markup Language)에 대한 저장 및 검색에 대한 연구가 활발히 진행되고 있다. 또한, 이들 XML 형식의 데이터를 생성, 변경, 조작하기 위한 여러 표준들과 툴들이 등장하면서 구조가 다른 많은 XML 문서들도 증가되고 있다. 이러한 상황에서, 서로 상이한 구조를 가진 대규모 XML 문서들의 데이터 저장을 최적화하고, 이들로부터 필요한 정보를 쉽고 빠르게 추출하는 것은 매우 중요한 이슈가 되고 있다.

XML 문서에 대한 효율적인 경로 검색 지원을 위해 여러 XML 인덱스들이 제안되었다. 이들은 한 개의 대규모 XML 문서나 동일한 구조를 가진 여러 XML 문서들에 대한 효율적인 경로 검색 지원을 목표로 하고 있다. 그러므로 구조가 다른 여러 XML 문서들로부터 원하는 경로를 찾기 위해 이러한 인덱스들을 사용하는 경우, 우리는 각 XML 문서들에 대해 따로 인덱스를 구성하고, 모든 인덱스들을 검사해야 한다. 게다가, 찾는 경로가 조상-자손관계로 표현되는 경우, 구축된 인덱스들의 모든 노드(node)들을 방문해야만 원하는 경로를 찾을 수 있어, 검색 성능이 급격히 떨어지게 된다. 이를 보완하기 위한 인덱스가 제안되기도 하였으나, 루트가 아닌 경로 중간에 조상-자손 관계가 나타나는 경우, 성능이 떨어지는 단점을 가진다.

한편, 구조가 다른 XML 문서들을 함께 검색할 수 있는 통합 인덱스들도 제안되었는데, 이들은 정보 검색 분야에서 RDBMS 기반 역 인덱스에 XML의 구조적 성질을 반영시켜 확장하는 방식을 취하였다. 또한 인덱스내의 모든 노드 정보들을 데이터베이스내의 테이블에 저장하여 안정적으로 관리 될 수 있도록 구성하였으며, 데이터베이스 시스템에서 제공하는 효율적인 질의 처리 지원 기능들을 경로 검색에 이용함으로써 경로 검색을 위한 추가적인 구현을 막고 효율적인 검색을 지원하였다. 하지만, 제안된 인덱스들 중 문서의 수가 증가함에 따라 비교/검색해야 할 인덱스내의 데이터가 증가하게 되어 검색성능이 저하되며, 구조가 다른 문서들이 늘어날수록 성능이 떨어지는 단점을 보인다. 이러한 특징은 대량의 XML 문서들에 대한 경로 검색을 필요로 하는 상황에서, 이들을 적용하게 어렵게 만드는 요인으로 작용한다.

개별 XML 문서를 파일의 형태로 특정 폴더에 저장하는 파일시스템 기반의 저장방식을 살펴보면 문서 전체에 대한 추가 작업이 파일단위로 이루어지므로 상대적으로 저장 및 추출 속도가 빠른 반면, XML 문서의 추출 시마다 XML 파싱이 필요하므로 비효율적이며, 파일시스템의 한계로 인한 문서 개수 및 폴더 개수의 제한이 있고, 동시 사용자 접속에 대한 지원 및 접근제어 기능 구현이 불가능하고 XML 처리를 위한 모든 기능들을 별도로 구현할 필요성과 더불어 검색을 위해 추가적인 DBMS 사용이 필요하다. XML 문서를 RDBMS의 BLOB이나 CLOB의 형태로 저장하는 통합RDBMS 기반의 저장방식을 살펴보면 문서의 저장 및 추출 속도가 빠른 반면, 문서의 부분 수정이나 검색에 많은 시간이 소요되고 XML 문서에 대한 처리가 필요할 때마다 문서 전체를 메모리에 불러서 사용해야 하므로 많은 메모리와 시간이 필요하며 XML 처리를 위한 모든 기능들을 별도로 구현해 주어야 한다.

XML 문서를 구성하는 각 요소들의 단위로 분할하여 table의 field에 저장하는 분할 RDBMS 기반의 저장방식을 살펴보면 문서의 부분 수정이나 검색을 빠르게 수행할 수 있는 반면, 문서의 저장시 분할 작업을 수행하고 여러 table을 접근해야 하므로 많은 시간이 소요되고, 문서의 추출시 여러 table에 대한 join 과정을 거치므로 매우 느리며, 문서의 서식이 변경되거나 추가될 때마다 DB table의 설계를 변경하거나 추가해야 하므로 확장이 어렵고, XML 처리를 위한 모든 기능들을 별도로 구현해 주어야 한다.

따라서, 본 발명은 위에서 언급한 문제점, 즉, 구조가 다른 문서들이 늘어날수록 검색 성능이 떨어지는 단점이나, 파일시스템 기반의 저장방식에서 발생하는 문제점들을 해결하기 위해, XML 문서의 스키마정보와 엘리먼트정보를 문서의 복잡성이나 크기에 관계없이 추출할 수 있도록 설계하고, 저장되는 데이터베이스 테이블의 속성은 XML 문서 구조의 추가, 변경에 관계없이 고정된 스키마 및 엘리먼트정보만 저장되므로 물리적 저장공간의 최적화 및 테이블 관리의 효율성을 제고한다.

또한, 사용자 질의를 자연어에 가까운 XQuery 명령으로 전달받고 자동으로 SQL 명령으로 변환하여 실행하는 방식을 제공함으로써 기존의 성숙된 데이터베이스 기술을 최대로 활용할 수 있으며, 향상된 검색 성능을 제고한다.

전술한 바와 같은 목적을 달성하기 위한 본 발명의 XML DB 구축방법에 따르면, XML 문서로부터 스키마 구조정보와 엘리먼트 경로정보를 추출하여 고정된 RDBMS 모델 기반의 XML DB를 구축하는 방법에 있어서, (A1)XML 문서의 스트링 데이터를 파싱하여 개별 스키마 구조정보(레벨, 형제순서, 속성순서, 엘리먼트명, 부모레벨, 부모형제순서, 부모속성순서)를 스키마정보파일로 생성하는 단계; (A2)개별 엘리먼트 경로정보(문서번호, 레벨, 형제순서, 속성순서, 상기 시작번호, 상기 종료번호, 데이터값)를 엘리먼트정보파일로 생성하는 단계; (A3)상기 단계(2)의 스키마정보파일로부터 상기 스키마 구조정보를 스키마테이블에 저장(insert)하는 단계; 및 (A4)상기 단계(3)의 엘리먼트정보파일로부터 상기 엘리먼트 경로정보를 엘리먼트테이블(문서번호, 레벨, 형제순서, 속성순서, 시작번호, 종료번호, 데이터값)에 저장하는 단계를 포함하여 이루어져, 상이한 구조의 복수개 XML 문서를 인덱싱 기법을 통하여 단일의 XML DB에 저장하는 것을 특징으로 한다.

또한, XQuery 명령을 통하여 XML DB에 접근하는 본 발명의 XML 엔진 시스템에 따르면, XML 파서 명령, XQuery 명령 또는 일반 SQL 명령을 전달하고 그 처리결과를 리턴받는 XML 엔진; 상기 XML 엔진으로부터 상기 XML 파서 명령을 제공받아 파서 실행을 제어하고, 상기 XQuery 명령을 SQL 명령으로 변환하고, 상기 SQL 명령으로 XML DB를 검색하여 받은 결과를 결과 XML 문서로 변환하여 상기 XML 엔진으로 리턴하는 XML 어댑터; 상기 XML 어댑터에 의해 실행되고, 상기 XML 엔진이 지정하는 입력 XML 문서를 파싱하여 스키마정보와 엘리먼트정보를 생성하는 XML 파서; 및 상기 XML 어댑터로부터 상기 스키마정보와 엘리먼트정보의 데이터를 전달받아 저장하고, 상기 SQL 명령의 실행에 의하여 검색된 결과를 상기 XML 어댑터로 리턴하는 XML DB를 포함하여 이루어지는 것을 특징으로 한다.

또한, 본 발명의 XML 엔진 시스템의 수행방법에 따르면, (1)XML 파서가 입력 XML 문서에 파싱을 수행하여 XML DB를 구축하는 단계; (2)XML 어댑터가 XQuery 명령을 SQL 명령으로 변환하는 단계; (3)XML 어댑터가 상기 SQL 명령을 상기 XML DB에서 실행하는 단계; 및 (4)상기 XML DB의 실행 결과를 결과 XML 문서로 생성하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

본 발명의 바람직한 특징에 따르면, 상기 단계(2)는, (2-1)상기 XQuery 명령을 실행하는 단계; (2-2)XML 엔진이 상기 XQuery 명령을 전달받는 단계; (2-3)상기 XML 엔진이 XQuery 구문 파싱 후 어댑터 명령어로 변환하여 상기 XML 어댑터로 전달하는 단계; (2-4)상기 XML 어댑터가 상기 어댑터 명령어로부터 Path Expression을 추출하는 단계; (2-5)입력 XML 문서의 스키마정보를 해쉬 테이블에 저장하는 단계; (2-6)상기 어댑터 명령어로부터 처리대상이 되는 Path Class를 추출하는 단계; 및 (2-7)상기 SQL 명령을 생성하는 단계를 포함하여 이루어지는 것을 특징으로 한다.

본 발명은 서로 다른 구조를 갖는 대용량의 XML 문서를 XML DB로 구축하고, 사용자가 실행하는 XQuery 명령을 SQL 명령으로 변환하여 XML DB에서 실행하고, 실행 결과를 XML 문서로 생성하여 사용자에게 리턴하는 XML 엔진 시스템과 그 수행방법에 관한 것이다. 본 발명에서는 전술한 기술을 XML DB 구축기술과, XQuery로 XML DB에 접근하는 XML 엔진 기술로 구분하여 설명한다. 전자의 기술은 도 1 내지 도 8을 통하여 설명하고, 후자의 기술은 도 9 내지 도 14를 통하여 설명한다.

이하 첨부된 도면에 의해 상세히 설명하면 다음과 같다.

도 1은 XML DB 구축방법의 개략적 기능도이다.

본 발명에서의 XML DB 구축방법은 XML 문서(100) 파일을 읽고 파싱을 수행하여 각 엘리먼트(element)에 대하여 레벨정보(element depth), 순서정보(element sequence), 속성정보(element attribute), 엘리먼트명(element name), 부모정보(parent element), 시작번호(start position), 종료번호(end position)를 추출(evaluation)한 후, 이들 정보를 XML DB(5)에 저장한다.

도 1을 참조하면, XML 문서(100)로부터 스트링 데이터(string data)를 읽어 들여서 XML SAX 파서(4)를 통하여 XML 문서(100)를 파싱(parsing)한다. XML 문서(100)를 파싱한 결과 DOM(Document Object Model) 트리(tree) 구조로 만들어진 데이터를 가지고 각 엘리먼트에 시작번호, 종료번호를 할당한다. 그리고, 트리 구조의 XML에서 각종 정보를 추출한다. 추출된 각 엘리먼트의 레벨정보, 순서정보, 속성정보, 값 등은 RDBMS 의 고정된 테이블로 XML DB(5)에 저장된다.

도 2는 본 발명의 기술을 설명하기 위한 예제 XML 문서로서, 도서관에서의 책 목록 정보를 XML 문서로 구현한 BOOK.XML의 데이터를 예시한다. XML 문서는 개별 엘리먼트(element)로 구성되고, 각 엘리먼트는 다시 스키마 엘리먼트(schema element)와 실제 데이터에 해당하는 데이터 엘리먼트(data element)로 구성된다.

도 3은 도2의 XML 문서를 파싱 후 분리된 전체 엘리먼트(E1~E14)들의 시작번 호와 종료번호를 정하는 방법을 나타낸 도면이다. 도 1에서 본 바와 같이 XML 문서는 파싱한 후 엘리먼트가 DOM 트리 구조로 만들어진다. 여기서 각 엘리먼트에 시작번호와 종료번호를 부여하는 방법은 트리의 깊이우선탐색(DFS : Depth First Search) 순서에 의한 것으로 다음과 같다.

제일 처음 시작되는 books(E1) 엘리먼트(root)에 시작번호를 0으로 할당한다. books(E1) 엘리먼트의 자식인 title(E2) 엘리먼트의 시작번호를 1로 할당한다. title(E2) 엘리먼트의 스트링 값인 'Data Model'(E3)의 시작번호를 2로, 종료번호를 3으로 할당한다. 스트링 값 'Data Model'(E3)의 부모인 title(E2) 엘리먼트의 종료번호를 4로 할당한다.

books(E1) 엘리먼트의 자식이며, title(E2) 엘리먼트의 형제인 section(E4) 엘리먼트의 시작번호를 5로 할당한다. section(E4) 엘리먼트의 자식인 title(E5) 엘리먼트의 시작번호를 6으로 할당한다. title(E5) 엘리먼트의 스트링 값인 'Syntax For Data Model'(E6)의 시작번호를 7로 종료번호를 8로 할당한다. 스트링 값 'Syntax For Data Model'(E6) 의 부모인 title(E5) 엘리먼트의 종료번호를 9로 할당한다. title(E5) 엘리먼트의 부모인 section(E4) 엘리먼트의 종료번호를 10으로 할당한다.

전술한 깊이우선탐색 순서에 의하여 나머지 엘리먼트(E7~E14)의 노드에 시작번호와 종료번호를 부여한다.

도 4는 본 발명에 따른 XML DB 구축방법의 전체 순서를 도시한다.

스키마정보파일 생성단계(SA10)에서는 입력되는 XML 문서 파일로부터 파싱을 수행하여 스키마정보를 추출하고 그 구조정보를 텍스트 형식의 파일로 저장한다.

엘리먼트정보파일 생성단계(SA20)는 전술한 단계(SA10)와 병행하여 수행되는 단계로서, 파싱을 통하여 개별 엘리먼트정보를 추출하고 그 경로정보 및 데이터값을 텍스트 파일로 저장한다.

스키마테이블 저장단계(SA30)에서는 전술한 단계(SA10)의 산출물인 스키마정보파일로부터 데이터를 읽어서 스키마테이블에 저장하여 XML DB를 구축한다.

엘리먼트테이블 저장단계(SA40)는 전술한 단계(SA20)의 산출물인 엘리먼트정보파일로부터 데이터를 읽어서 엘리먼트테이블에 저장하여 XML DB를 구축한다.

도 5는 XML SAX를 실행하여 XML 문서의 스키마 구조정보 및 엘리먼트 경로정보를 추출하고 텍스트 파일을 생성하는 과정의 순서도이다.

먼저, 스키마 구조정보 추출 및 파일 생성을 설명하면 다음과 같다.

XML 파서로서 Sax를 실행하면 가장 먼저 단계(SA11)를 실행한다.

StartElement 함수 처리단계(SA11)에서는 현재위치를 1로 레벨(Depthid)을 29999으로 초기화한다. 문서번호(문서id)는 DB의 최종문서번호에 1 증가시킨 값이다. Element 읽기 처리단계(SA12)에서는 각각의 엘리먼트를 순차적으로 읽는다. Element 비교단계(SA13)에서는 읽은 엘리먼트의 구문을 비교하여 시작('< >'), 종료('</ >') 엘리먼트에 따라 각각의 함수를 처리한다.

시작 엘리먼트일 경우, startElement 함수 처리단계(SA14)에서는 현재 엘리먼트의 레벨을 1 증가시킨다. 엘리먼트시퀀스 해쉬에 현재 엘리먼트의 레벨+엘리먼트명+부모레벨+부모엘리먼트명이 존재하면 레벨의 형제순서의 변동없이 다음 단계 로 분기하고, 그렇치 않으면 레벨의 형제순서를 1증가시킨 후 레벨+엘리먼트명+부모레벨+부모엘리먼트명으로 엘리먼트시퀀스 해쉬에 형제순서를 추가 저장한다. 이것은 동일 부모를 갖는 형제 중에서 같은 이름의 스키마정보를 중복하여 저장하지 않음으로써 처리속도를 빠르게하고 저장 데이터의 양을 줄이는 역할을 한다.

또한, 스키마정보파일에 레벨, 형제순서, 속성순서('0'), 엘리먼트명, 부모레벨(현재레벨-1), 부모형제순서(엘리먼트시퀀스 해쉬에서 부모레벨+부모엘리먼트명+조부모레벨+조부모엘리먼트명을 key로 검색), 부모속성순서('0')를 저장한다.

속성비교단계(SA15)에서는 엘리먼트의 속성 유무를 체크하여 존재하는 경우 단계(6)를 실행하고 없으면 단계(2)를 실행한다.

속성순서 처리단계(SA16)는 엘리먼트의 속성순서를 파일 저장하기 위한 것으로 레벨을 1 증가시킨다. 속성시퀀스 해쉬에 레벨+속성명+부모레벨+부모엘리먼트명이 존재하면 레벨의 속성순서는 변동 없이 다음 단계로 분기하고, 그렇치 않으면 레벨의 속성순서를 1증가시킨 후 레벨+속성명+부모레벨+부모엘리먼트명으로 속성순서 해쉬에 속성순서를 추가 저장한다. 스키마정보파일에 레벨, 형제순서('0'), 속성순서, 엘리먼트명, 부모레벨(현재레벨-1), 부모형제순서(엘리먼트시퀀스 해쉬에서 부모레벨+부모엘리먼트명+조부모레벨+조부모엘리먼트명을 key로 검색), 부모속성순서('0')를 저장한다. 현재레벨을 1 감소시킨다.

endElement 함수 처리단계(SA17)에서는 엘리먼트가 종료되는 경우로, 현재 엘리먼트의 레벨을 1 감소시킨다. endDocument 함수 처리단계(SA19)에서는 XML 문서의 끝을 만난 경우로, XML SAX의 실행을 종료한다.

도 6은 도 2의 XML 문서가 도 5의 과정을 거친 후, 스키마정보파일에 생성된 E1, E2, E4, E5, E10, E11 엘리먼트로 구성된 스키마 구조정보 데이터를 도시한다. 각 행에서 열의 구분은 콤마(,)로 구분된다. 각각의 행은 구조가 다른 스키마의 구조정보이고, 열은 표 1을 통하여 표시한다.

제 1열	제 2열	제 3열	제 4열	제 5열	제 6열	제 7열
엘리먼트 레벨	엘리먼트 형제순서	동일 엘리먼트 내의 속성순서	부모 엘리먼트 레벨	부모 엘리먼트 형제순서	부모 엘리먼트 내의 속성순서	엘리먼트명

다음으로, 아래에서는 엘리먼트 경로정보를 추출하여 텍스트 파일을 생성하는 단계(SA21 ~ SA29)과정을 설명하며, 병행적으로 동작하는 전술한 단계(SA11 ~ SA19)의 과정과 동일한 과정은 생략하기로 한다.

엘리먼트 비교단계(SA23)에서는 읽은 엘리먼트의 구문을 비교하여 시작('< >'), 종료('</ >'), 값(characters)에 따라 각각의 함수를 처리한다.

startElement 함수 처리단계(SA24)에서는 엘리먼트가 시작되는 경우로, 현재 위치 및 레벨을 1 증가시킨다. 레벨 해쉬에는 현재레벨과 현재레벨+현재엘리먼트명을 각각 저장한다. 시작번호 해쉬에는 현재레벨+현재엘리먼트명+부모레벨+부모엘리먼트명과 시작번호(현재위치)를 각각 저장한다.

엘리먼트 속성값 처리단계(SA26)에서는 엘리먼트의 속성값을 파일 저장하기 위한 것으로 현재위치를 1 증가하고 현재레벨(Depthid)을 1 증가시킨다. 레벨 해쉬에는 현재레벨과 현재레벨+현재속성이름을 저장한다. 시작번호 해쉬에는 현재레벨+ 현재속성명+부모레벨+부모엘리먼트명과 시작번호(현재번호)를 저장한다. 종료번호는 현재위치를 1 증가한 값이다. 엘리먼트정보파일에 엘리먼트의 문서번호, 레벨, 형제순서('0'), 속성순서(도 4의 속성순서 해쉬에서 현재레벨(Depthid)+현재속성이름+부모레벨(Depthid)+부모엘리먼트명을 key로 검색), 시작번호, 종료번호, 데이터값을 저장한다. 현재레벨(Depthid)을 1 감소시킨다.

endElement 함수 처리단계(SA27)에서는 엘리먼트가 종료되는 경우로, 현재위치를 1 증가시킨 후, 종료번호에 현재위치를 저장한다. 엘리먼트정보파일에 문서번호, 레벨, 형제순서(도 4의 엘리먼트시퀀스 해쉬에서 현재레벨+현재엘리먼트명+부모레벨+부모엘리먼트명을 key로 검색), 속성순서('0'), 시작번호(시작번호 해쉬에서 현재레벨+현재엘리먼트명+부모레벨+부모엘리먼트명을 key로 검색), 종료번호, 데이터값을 저장한다. 현재레벨을 1 감소시킨다.

character 함수 처리단계(SA28)에서는 데이터 엘리먼트를 만난 경우로, 현재위치를 1 증가시킨 후, 시작번호에 현재위치를 저장한다. 다시, 현재위치를 1 증가시킨 후, 종료번호에 현재위치를 저장한다. 엘리먼트정보파일에 현재문서번호, 현재레벨, 형제순서(도 4의 엘리먼트시퀀스 해쉬에서 현재레벨(Depthid)+현재엘리먼트명+부모레벨(Depthid)+부모엘리먼트명을 key로 검색), 속성순서('0'), 시작번호, 종료번호, 데이터값을 저장한다.

도 7은 도 2의 XML 문서를 도 5의 과정을 거친 후, 엘리먼트정보파일에 생성된 엘리먼트 경로정보 데이터를 도시한다. 각 행에서 열의 구분은 콤마(,)로 구분된다. 각각의 행은 XML 문서에서 실제 사용되는 전체 엘리먼트의 경로 및 내용정보 이고, 열은 다음과 같은 정보를 나타낸다.

제 1열	제 2열	제 3열	제 4열	제 5열	제 6열	제 7열
문서번호	레벨(레벨id)	형제순서	속성순서	시작번호	종료번호	엘리먼트값

도 8은 도 5의 과정을 거쳐서 각각 생성된 도 6 및 도 7의 텍스트 파일의 데이터를 XML DB에 저장한 table구조를 도시한다. 스키마 테이블은 XML문서의 스키마 구조정보(도6)를, 엘리먼트테이블은 각 엘리먼트의 경로정보 및 값(도7)을 저장하는 고정화된 테이블 구조이다.

다음은 스키마 테이블의 구체적인 속성 정보를 표 3에 표시한다. (단, 동일 부모 하에 레벨정보와 엘리먼트명이 동일한 경우에는 동일 스키마 구조로 간주하여, 최초 엘리먼트정보만 엘리먼트테이블에 저장한다.)

A	B	C	D	E	F	G
엘리먼트 레벨	엘리먼트 형제순서	엘리먼트 속성순서	엘리먼트명	부모엘리먼트 레벨	부모엘리먼트 형제순서	부모엘리먼트 속성순서

다음은 엘리먼트테이블의 구체적인 속성 정보를 표 4에 표시한다.

I	J	K	L	M	N	O
문서번호 (문서id)	엘리먼트 레벨	엘리먼트 형제순서	엘리먼트 속성순서	시작번호	종료번호	엘리먼트값(characters)

도 9는 본 발명에 따른 XML 엔진 시스템(1)의 기능을 도시한다. 본 발명의 XML 엔진 시스템(1)은 XML 엔진(2), XML 어댑터(3), XML 파서(4) 및 XML DB(5)를 포함하여 구성된다.

본 발명의 XML 엔진 시스템(1)은 실시자의 설계 변경을 통하여 콘솔의 독립(stand alone)환경에서 관리자의 입력으로 제어될 수 있고, 또한, 네트워크를 통하여 명령을 전달받고 서버에서 처리한 실행결과를 다시 클라이언트로 리턴하는 클라이언트/서버 환경에서 클라이언트의 입력으로 제어될 수 있다.

XML 엔진 시스템(1)은 관리자의 XML DB(5) 접근을 인터페이스하며, 다음과 같은 총 3가지 기능을 수행하고 그 기능은 다음과 같다.

제 1기능은 XML DB 생성기능으로서, 관리자가 지정하는 입력 XML 문서를 전달받고, XML 파서(4)의 실행을 제어하여 XML DB(5)에 스키마 테이블 및 엘리먼트테이블을 구축한다(도 1 내지 도 8을 통하여 전술하였음). 제 2기능은 XQuery 실행기능으로서, 관리자가 입력하는 XQuery 명령이 XML DB(5)에서 실행될 수 있도록 XQuery 명령을 SQL 명령으로 변환하여 실행하는 것이다. 여기서, 관리자로부터 SQL 명령을 전달받고 직접 XML DB(5)에서 실행하는 것도 가능하다. 제 3기능은 결과 XML 문서 생성기능으로서, XML DB(5)에서 실행된 결과 데이터를 XML 문서로 생성하여 관리자에게 리턴한다.

XML 엔진(2)은 XML 엔진 시스템(1)의 전체 기능을 총괄 제어하는 역할을 하며 관리자와 XML 엔진 시스템(1) 사이에서 인터페이스하고, 관리자가 요청하는 XML DB 구축명령, XQuery 명령, SQL 명령을 전달받고 XML 어댑터(3)를 통하여 XML 파서(4) 및 XML DB(5)로 명령을 전달하여 실행하도록 제어한다.

XML 어댑터(3)는 XML 엔진(2)으로부터 XML 문서를 전달받아 XML 파서(4) 실행을 제어하고, XQuery 명령을 전달받아 SQL 명령으로 변환하여 XML DB(5)에서 실행한 결과를 결과 XML 문서로 변환하여 XML 엔진(2)으로 다시 리턴한다.

XML 파서(4)는 XML 어댑터(3)에 의해 실행되고, XML 엔진(2)이 전달받은 입력 XML 문서를 파싱하여 스키마정보와 엘리먼트정보를 생성한다(전술한 도 1 내지 도 8의 기술).

또한, XML DB(5)는 다양한 구조를 갖는 XML 문서 파일에 대하여 스키마정보와 엘리먼트정보를 저장하는 테이블을 구비하고, 그 테이블의 구조는 7개 필드 항목으로 각각 고정되어 어떠한 형식의 XML 문서라도 DB화가 가능하다.

도 10은 본 발명에 따른 XML 엔진 시스템의 개략적 구성을 도시한다.

본 발명의 XML 엔진(2)은 스캐너부(21), 파서부(22) 및 명령어 생성부(23)를 포함하여 구성된다. 스캐너부(21)는 XQuery 원시구문을 파싱을 통하여 토큰 스트링으로 분리한다. 파서부(22)는 토큰 스트링으로부터 구문분석을 통하여 구문트리를 생성한다. 명령어 생성부(23)는 구문트리로부터 어댑터 명령어를 생성한다. XML 엔진(2)의 보다 상세한 설명은 도 14를 통하여 후술하도록 한다.

또한, 본 발명의 XML 어댑터(3)는 파서 실행부(31) XQuery 변환부(32) SQL 실행부(33), 결과 XML 문서 생성부(34) 드라이버 관리부(35) 및 결과 리턴부(36)를 포함하여 구성된다.

파서 실행부(31)는 입력 XML 문서에 대하여 XML 파서(4)를 실행하고 처리결과로서 스키마의 구조정보와 엘리먼트의 경로정보를 전달받고 XML DB(5)에 저장한 다. XQuery 변환부(32)는 명령어 생성부(23)로부터 명령어를 전달받아 SQL 명령으로 변환한다. SQL 실행부(33)는 변환된 명령을 XML DB(5)에 실행한다. 결과 XML 문서 생성부(34)는 XML DB(5)에서의 실행 결과를 XML 파일로 생성한다. 드라이버 관리부(35)는 XML 어댑터(3)의 장치 관리 드라이버로 XML DB(5)와 인터페이스한다. 결과 리턴부(36)는 XML DB(5)로부터의 결과를 XML 엔진(2)으로 리턴한다.

도 11은 본 발명에 따른 XML 엔진(2)이 XQuery 명령을 변환하여 XML 어댑터(3)가 처리하는 명령어로 변환하는 과정의 기능을 도시한다.

XML 엔진(2)에서는 XQuery구문을 토큰하여 파싱 후 XML 어댑터(3)에 보낼 명령어를 생성한 후 보내면 XML 어댑터(3)에서는 명령어를 처리한 후 XML 엔진(2)으로 리턴하고, XML 엔진(2)이 명령을 실행한 관리자가 최종적으로 원하는 곳(클라이언트, API 등)에 결과를 리턴한다.

도 12는 본 발명에 따른 XML 엔진 시스템의 수행방법에 대한 전체 순서를 도시한다.

XML DB 구축단계(S10)에서는 XML 파서(4)가 입력 XML 문서에 파싱을 수행하여 XML DB를 구축한다. SQL 명령 변환단계(S20)에서는 XML 어댑터(3)가 XQuery 명령을 SQL 명령으로 변환한다. SQL 명령 실행단계(S30)에서는 XML 어댑터(3)가 SQL 명령을 XML DB(5)에서 실행한다. 결과 XML 문서 생성단계(S40)에서는 XML 어댑터(3)가 XML DB(5)에서의 실행 결과를 결과 XML 문서로 생성한다.

도 13은 본 발명에 따른 XQuery 명령 변환단계(SA20)의 상세 순서를 도시한다.

XQuery 명령 실행단계(S21)에서는 관리자가 클라이언트/서버 환경 또는 단독 독립 환경에서 XML 데이터에 대한 XQuery 명령을 실행한다. XQuery 명령 전달받는 단계(S22)에서는 XML 엔진(2)이 XQuery 명령을 전달받는다.

어댑터 명령어 생성기 전달단계(S23)는 도 14에 도시한 바와 같은 상세 순서를 참조하여 설명한다.

토큰 생성단계(S231)에서는 XQuery 엔진(2)이 W3C XQuery 명세에 따른 원시 코드 즉 XQuery 구문을 입력받아서 문자의 나열에서 단어와 같은 토큰이라고 하는 의미 있는 단위를 골라내는 어휘 분석(Lexical analysis)을 실시한다. 토큰은 자연 언어의 단어와 유사하다. 스캐너부(21)에 의해 잘려진 각각의 토큰은 원시 프로그램에서 정보의 단위를 표현하는 문자열을 의미한다. XQuery엔진의 토큰의 대표적인 예로써는 for, let, where, return과 같은 고정된 문자열로 구성되는 키워드(keyword), 사용자-정의한 문자열로써 보통 영문자로 시작하고 영문자, 숫자들로 구성되는 식별자(identifier), 산술연산자인 +,* 등의 문자와 여러 개의 문자들로 구성되는 >=, <> 등의 특수기호(special symbol) 등이 있다. 이러한 각각의 토큰은 스캐너에 의해서 입력되는 문자들의 인식 혹은 일치(match)하는 특정한 문자 패턴을 표시한다. 스캐너부(21)는 이 외에 명세에 정의된 식별자를 심볼 테이블에 넣는 작업을 하거나 리터럴(literal)을 리터럴 테이블에 넣는 작업 등 여러 부가적인 작업을 한다.

예를 들어 원시 코드(클라이언트에서 입력한 XQuery명령)이 dbdoc("books.xml") /books/section일 때, 위의 원시코드는 데이터베이스에 저장된 books.xml Document의 XML에서 루트 노드인 books(E1) 노드의 하위노드인 section(E4, E7) 노드를 추출해오는 명령이다

위에서 입력된 원시코드는 표 5와 같은 토큰이 된다.

dbdoc - function(pre defined function library) books.xml - String literal(문자열) books - childstep Expression(하위노드) section - childstep Expression(하위노드)

구문트리 생성단계(S232)에서는 파서부(22)가 스캐너부(21)로부터 토큰으로 나누어진 원시 프로그램을 받아서 프로그램의 구조를 결정하는 구문 분석(syntax analysis)을 수행한다. 구문 분석 결과는 구문트리(syntax tree)로 나타낸다. 스캐너에 의해 인식되는 토큰의 어휘 구조가 정규 표현식에 의해서 주어지는 것과 유사한 방법으로 프로그래밍 언어의 구문은 일반적으로 문맥 자유 문법의 문법 규칙에 의해 주어진다. 파싱에 사용되는 기본적인 구조는 구문트리이다. 표 5에서의 토큰은 아래의 표 6과 같은 결과로 변환된다.

Query declarations = body = PathExpr at 0, type element()* flags: O steps = * Call fn:dbdoc( $uri as xs:string? ) as document()? at 0, type document()? flags: O D args = * StringLiteral 'books.xml' at 6, type xs:string flags: C * ChildStep at 20, type element()* flags: O D nodeTest = nodeTest(2, :books) * ChildStep at 26, type element()* flags: O D nodeTest = nodeTest(2, :section)

Declarations - W3C XQuery Specification에서의 정의에 따라 선언부를 해석한다. Body - 메인 쿼리 부분을 담당하는 트리 PathExpr - 위 예제 표현식은 XML문서에서 Path를 찾아가는 Path Expression으로 된다 Call - dbdoc function을 호출한다. ChildStep - xml document의 books 노드를 찾는다 ChildStep -books노드의 하위노드인 section을 찾는다

어댑터 명령어 생성단계(S233)에서는 어댑터 명령어 생성부(23)가 각 구문트리로부터 데이터베이스 연동을 위한 어댑터가 인식할 수 있는 어셈블리어 같은 명령어(command)를 생성하는 모듈이다. 어댑터는 이 명령어를 수행하여 결과 XML스트림을 출력하여 젼송한다. 어댑터 명령어 생성기는 예약어 및 심볼, 함수등 XQuery질의 처리를 위해 어댑터와 엔진간에 정해진 명령어 체계를 따른다

예를 들어 위의 파서부(22)의 수행에 의해 생성된 결과트리는 어댑터 명령어 생성기에 의해 Database XML Indexed search를 위해 아래의 표 7과 같은 어댑터 명령어(Command)를 생성한다.

command: 1 PathExpr command: 2 fn:doc() db_041007_090018.xml command: 3 StringLiteral books.xml command: 4 ChildStep books command: 5 ChildStep section command: 6 PathExpr End

어댑터 명령어 전달단계(S234)에서는 XML 엔진이 생성한 표 7에서와 같은 명령어를 XML 어댑터(3)로 전달한다.

도 13의 Path Expression 추출단계(S24)에서는 XML 어댑터(3)가 먼저 XML 엔진(2)에서 보내온 명령어를 받고 XML-DB(Native DB, RDBMS)에서 쓰는 명령어만 추 출한다. 다시 말해 fn:doc()명령, FLOWER명령, PATHEXPR명령, PATHEXPR_END명령, FORCLAUSE명령, FORCLAUSE_END명령, LETCLAUSE명령의 XML-DB에서 사용하지 않은 명령어는 제외하는 것이다.

마지막으로 추출한 명령어 정보를 처리단위별로 벡터(Vector)를 만들어 리턴한다.

예를 들면 클라이언트에서 위의 BOOKS.XML에서 /books/section 인 값을 가져오라는 XQuery구문인 dbdoc("books.xml") /books/section을 실행을 하면 엔진에서 보내온 명령어는 표 7과 같다. 여기에서 PathExpr, fn:doc(), PathExpr End 명령을 제외시키고 필요한 항목만 뽑아내면 아래의 표 8과 같다.

command: StringLiteral;books.xml command: ChildStep;books command: ChildStep;section

스키마정보 해쉬테이블 저장단계(S25)에서는 위와 같은 벡터의 데이터를 가지고 실행을 하기 전에 먼저 현재 스키마정보인 레벨(DEPTHID), 노드id(NODEID), 속성id(ATTRID), 부모레벨(PAR_DEPTHID), 부모노드id(PAR_NODEID), 부모속성id(PAR_ATTRID), 엘리먼트명(ENAME)을 스키마 테이블에서 조회한 후, 해쉬 테이블에 저장을 하는데 키는 현재 엘리먼트의 정보인 레벨(DEPTHID), 노드id(NODEID), 속성id(ATTRID)이고, 해쉬테이블 값은 레벨(DEPTHID), 노드id(NODEID), 속성id(ATTRID), 부모레벨(PAR_DEPTHID), 부모노드id(PAR_NODEID), 부모속성 id(PAR_ATTRID), 엘리먼트명(ENAME)을 가지고 있는 elementClass를 저장한다.

예를 들어 위의 BOOKS.XML의 스키마 테이블의 데이터는 아래의 표 9와 같다.

레 벨	노드 id	속성 id	부모 레벨	부모노드 id	부모속성 id	엘리먼트명
30000	1	0	0	0	0	books
30001	1	0	30000	1	0	title
30001	2	0	30000	1	0	section
30002	1	0	30001	2	0	title
30002	2	0	30001	2	0	section
30003	1	0	30002	2	0	title

위의 데이터를 해쉬테이블에 저장을 하면 아래의 표 10과 같다.

해쉬테이블 키	해쉬테이블 값( elementClass 클래스)
30000/1/0	30000,1,0,0,0,0,books의 값이 저장되어 있는 elementClass
30001/1/0	30001,1,0,30000,1,0,title의 값이 저장되어 있는 elementClass
30001/2/0	30001,2,0,30000,1,0,section의 값이 저장되어 있는 elementClass
30002/1/0	30002,1,0,30001,2,0,title의 값이 저장되어 있는 elementClass
30002/2/0	30002,2,0,30001,2,0,section의 값이 저장되어 있는 elementClass
30003/1/0	30003,1,0,30002,2,0,title의 값이 저장되어 있는 elementClass

위의 해쉬테이블 키는 각 값들이 /로 연결되어있는 하나의 문자열이고 해쉬테이블 값은 elementClass의 각 변수들에 입력이 되어 있다.

Path Class 추출단계(S26)에서는 전술한 벡터에 저장된 명령어에서 먼저 변수명이나 파일명을 뺀 순수한 명령어만 추출한다. 예를 들어 위에서 벡터에 넣은 명령어는 아래의 표 8과 같고, 여기에서 순수한 명령어만 추출하면 아래 표 11과 같이 순수하게 데이터정보를 가져오는 명령어만 추출된다.

command: ChildStep;books command: ChildStep;section

필터 Expression과 Path Expression에 대한 의미는 XQuery명령인 /books/section은 위의 BOOKS.XML에서 루트가 books이고 그 밑에 엘리먼트가 section인 section항목들을 조회하는 명령이다.

여기에서 books와 section에는 []인 조건이 없어 Path Expression만 있는 경우고 /books/section[title='XML']은 위의 BOOKS.XML에서 루트가 books이고 그 밑에 엘리먼트가 section인 값들 중에 title이 XML인 section 항목값들을 조회하는 명령이다. 여기에서 /books/section[title='XML']은 books, section은 Path Expression 이고, [title='XML']는 조건이 있어 필터 Expression이다. 간단히 []가 없는건 Path Expression이고 있으면 필터 Expression이라고 생각하면 된다.

Path Class란 XML의 엘리먼트 단위로 command가 필터 Expression인지 Path Expression인지의 여부와 필터시퀀스의 값과 elementClass의 정보를 가지고 있는 Class이다. 또 필터시퀀스는 XQuery명령중에 [숫자]인 경우를 말한다. 예를 들어 /books/section[2][title='XML']과 같이 [2]라는 필터안에 숫자가 있는 경우가 필터시퀀스이다.

위의 경우에 명령어는 command: ChildStep;books 와 command: ChildStep;section이 있는데 이 명령을 PathClass로 나타내면 command: ChildStep;books는 PathClass에 Path Expression은 true로 필터 Expression은 false이고 필터시퀀스 값은 0이고 books에 대한 30000,1,0,0,0,0,books 정보를 가 지고 있는 elementClass를 저장한다. command: ChildStep;section는 PathClass에 Path Expression 은 true로 필터 Expression은 false이고 필터시퀀스 값은 0이고 section에 대한 30001,2,0,30000,1,0,section 정보를 가지고 있는 elementClass를 저장한다.

마지막으로 command에서 최종 대상이 되는 Path class를 추출하는데, 예를 들어 XQuery명령인 /books/section이 있으면 명령어는 books와 section인 엘리먼트가 구분되는데 둘다 []로 되어 있는 필터 명령이 아니므로 Path Expression 은 true로 필터 Expression은 false인데 최종적으로 조회할 엘리먼트는 section이므로 추출될 Path Class는 section의 Path class만 추출이 된다.

SQL 명령을 생성하는 단계(S27)에서는 전술한 단계의 Path class들의 정보를 이용하여 SQL을 생성하는 방법이다.

<필터 시퀀스가 없을 경우>

여기서 필터 시퀀스가 없는 경우란 XQuery명령이 /books/section[2][title='XML']인 경우, [2]인 필터안에 숫자인 값이 있는 경우는 필터 시퀀스가 있는 경우이고 XQuery명령이 /books/section과 같이 [숫자]값이 없는 경우가 필터 시퀀스가 없는 경우이다.

기본적인 SQL의 윗부분은 디폴트로 아래 표 12와 같다. 이 디폴트 SQL에 추가로 XQuery명령에 대한 결과SQL을 추가하는 것이다.

SELECT P0.DOCID, XX.DEPTHID, XX.NODEID, XX.ATTRID, XX.STARTPOS, XX.ENDPOS, XX.TERM, XX.TERM2 FROM 엘리먼트테이블 P0 , 엘리먼트테이블 XX ...... ORDERBY P0.DOCID, XX.STARTPOS

위의 SELECT 와 FROM절의 테이블을 디폴트로 하고 아래 표 13의 WHERE절을 where절의 디폴트로 한다.

WHERE P0.DOCID = XX.DOCID AND XX.STARTPOS >= P0.STARTPOS AND XX.ENDPOS <= P0.ENDPOS

위의 테이블이 기본조건이 된 이유는 xml에서 특정한 엘리먼트를 조회한다면 그 엘리먼트의 Startpos과 Endpos사이의 데이터를 조회하는 것과 같다. 여기서 특정한 엘리먼트는 P0에서 찾고 그 엘리먼트의 자식 데이터는 XX테이블에 STARTPOS과 ENDPOS를 조건에 주는 것과 같다.

예를 들어 BOOKS.XML에 XQuery명령으로 /books/section을 실행했을 때 도 3의 그림에서 보는 것처럼 section(E4, E7)의 밑에 있는 데이터를 다 가져 와야 하는데 section의 startpos과 endpos사이의 값 전체를 가져오면 원하는 데이터를 가져올 수 있는 것이다. 도 3에서는 /books/section 의 하위값들을 조회하려면 startpos이 5이고 endpos이 10 또 startpos이 11이고 endpos이 28인 데이터를 조회하면 books(E1)의 밑에 있는 section(E4, E7)의 자식 데이터를 전부 조회하는 것이다.

이 기본 SQL에 추출한 Path Class 정보들을 가지고 From절과 where절에 쿼리를 추가하여 쿼리를 만든다. 예를 들어 Path Class가 /books/section의 XQuery명령을 실행시킨 Path Expression 이면, 아래 표 14와 같이 section의 엘리먼트정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID), 내용(TERM)에 정보를 넣어 SQL에 추가를 한다.

P0.DEPTHID = 30001 AND P0.NODEID = 2 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '')

만약 Path Class가 /books/section[title='XML']의 XQuery명령을 실행시킨다면 [title='XML']인 필터 Expression이 있으므로, 아래 표 15와 같이 엘리먼트테이블 두개를 From절에 추가를 하는데 하나는 FP부모시퀀스인 필터 부모테이블의 의미이고 나머지 하나는 F필터시퀀스인 필터 테이블의 의미이다.

엘리먼트테이블 F0(0=현재시퀀스), 엘리먼트테이블 FP0(0=부모시퀀스)

Where조건에는 아래 표 16과 같이 필터의 부모 엘리먼트정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID), 내용(TERM)에 정보를 넣어 SQL에 추가를 하고 또 필터의 엘리먼트정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID)과 마지막으로 내용(TERM)에는 아래의 F0.TERM = 'XML'과 같이 필터의 조건식(=.>.<.>=.<= 등)과 값이 들어가서 SQL을 만든다.

예를 들어 /books/section[title='XML']의 XQuery명령을 실행하면 아래 표 16과 같이 FP0에는 title 의 부모 엘리먼트인 section의 엘리먼트정보들이 들어가고 F0에는 자신인 title의 엘리먼트정보들이 들어가고 마지막으로 F0.TERM = 'XML'과 같이 조건이 들어간다.

FP0.DEPTHID = 30001 AND FP0.NODEID = 2 AND FP0.ATTRID = 0 AND (FP0.TERM is null OR FP0.TERM = '' ) AND F0.DEPTHID = 30002 AND F0.NODEID= 1 AND F0.ATTRID = 0 AND F0.TERM = 'XML'

위의 쿼리에 또 다른 필터 Expression이 있다고 하자.

만일 /books/section[title='XML'][title= 'Basic']인 XQuery명령과 같이 [title= 'Basic']이 한 부모인 section에서 나온 것처럼 부모가 같다면 부모시퀀스는 증가하지 않고 그대로 하고 현재시퀀스만 증가하여 아래 표 17과 같은 SQL을 추가한다.

FP0.DEPTHID = 30001 AND FP0.NODEID = 2 AND FP0.ATTRID = 0 AND (FP0.TERM is null OR FP0.TERM = '' ) AND F1.DEPTHID = 30002 AND F1.NODEID= 2 AND F1.ATTRID = 0 AND F1.TERM = 'Basic'

/books/section[title='XML']/section[title='Basic Syntax']인 XQuery명령에서 이름은 필터들의 부모 엘리먼트명이 section으로 같아도 depth가 달라 다른 엘리먼트이므로 부모가 같지 않다. 부모가 같지 않다면 아래 표 18과 같이 부모시퀀스와 현재시퀀스를 증가하여 SQL을 추가한다.

FP1.DEPTHID = 30002 AND FP1.NODEID = 2 AND FP1.ATTRID = 0 AND (FP1.TERM is null OR FP1.TERM = '' ) AND F1.DEPTHID = 30003 AND F1.NODEID= 1 AND F1.ATTRID = 0 AND F1.TERM = 'Basic Syntax'

간단히 SQL을 만드는 예를 든다면

/books의 XQuery구문이 있다면 처리대상이 되는 Path Class 추출에서 books에 대한 정보들이 Path Class에 들어가서 넘어온다.

그 PathClass의 정보를 가지고 SQL을 만들면 아래 표 19와 같이 기본SQL에 books의 엘리먼트정보들이 있는 PathClass정보를 이용하여 P0.DEPTHID = 30000 AND P0.NODEID = 1 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') 인 엘리먼트정보를 추가하여 SQL문을 만든다.

SELECT P0.DOCID, XX.DEPTHID, XX.NODEID, XX.ATTRID, XX.STARTPOS, XX.ENDPOS, XX.TERM, XX.TERM2 FROM 엘리먼트테이블 P0, 엘리먼트테이블 XX WHERE P0.DOCID = XX.DOCID AND XX.STARTPOS >= P0.STARTPOS AND XX.ENDPOS <= P0.ENDPOS AND ( ( P0.DEPTHID = 30000 AND P0.NODEID = 1 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') ) ) ORDERBY P0.DOCID, XX.STARTPOS

<필터 시퀀스가 있을 경우>

여기서 필터 시퀀스가 있는 경우란 XQuery명령인 /books/section[2][title='XML']경우, [2]인 필터안에 숫자인 값이 있는 경우이다. 필터시퀀스가 있을 경우에는 먼저 [숫자]까지의 Path Class를 첫번째 sql로 만들어 처리한 후 그 이후의 Path Class 다시 두번째 sql로 만들어 데이터를 가져온다. 먼저 첫번째 sql의 디폴트 SQL은 아래 표 20과 같다. 먼저 이 sql은 Mysql에서 실행이 된다고 가정을 하자.

SELECT P0.DOCID, P0.DEPTHID, P0.NODEID, P0.ATTRID, P0.STARTPOS, P0.ENDPOS, P0.TERM, P0.TERM2 FROM 엘리먼트테이블 P0 ...... ORDER BY P0.DOCID, P0.STARTPOS limit [필터시퀀스 값]

위에서 보는 것처럼 이 SQL는 앞의 sql과는 달리 XX가 없다. 그 이유는 첫번째 SQL에서는 조회하고자 하는 엘리먼트를 찾고 실제 데이터는 첫번째에서 찾은 엘리먼트를 가지고 두번째 SQL에서 찾기 때문이다. 그러므로 첫번째 SQL에서는 해당 엘리먼트만 찾으므로 XX 테이블이 없다.

이 기본 SQL에 추출한 Path Class들 중 필터시퀀스 앞까지의 Path Class들을 가지고 From절과 where절에 쿼리를 추가하여 첫번째 쿼리를 만든다.

그 방법은 앞에서 한 것과 같이 Path Class가 Path Expression 이면 엘리먼트정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID), 내용(TERM)에 정보를 넣어 SQL에 추가하고 만약 Path Class가 필터 Expression 이면, 아래 표 21같이 엘리먼트테이블 두개를 From절에 추가하는데 하나는 FP부모시퀀스인 필터 부모테이블의 의미이고 나머지 하나는 F현재시퀀스인 필터 테이블의 의미이다.

Where조건에는 아래와 같이 필터의 부모 엘리먼트정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID), 내용(TERM)에 정보를 넣어 SQL에 추가하고 또 필터의 엘리먼트 정보를 나타내는 레벨(Depthid), 노드id(NodeID), 속성ID(ATTRID)과 마지막으로 내용(TERM)에는 아래의 F0.TERM = 'XML'과 같이 필터의 조건식(=.>.<.>=.<= 등)과 값이 들어가서 SQL을 만든다.

예를 들어 /books/section[title='XML']의 XQuery명령을 실행하면 아래 표 22와 같이 FP0에는 title 의 부모 엘리먼트인 section의 엘리먼트정보들이 들어가고 F0에는 자신인 title의 엘리먼트정보들이 들어가고 마지막으로 F0.TERM = 'XML'과 같이 조건이 들어간다.

위의 쿼리에 또 다른 필터 Expression이 있다고 하자.

만일 /books/section[title='XML'][title= 'Basic']인 XQuery명령과 같이 [title= 'Basic']이 한 부모인 section에서 나온 것처럼 부모가 같다면 부모시퀀스는 증가하지 않고 그대로 하고 현재시퀀스만 증가하여 아래 표 23과 같은 SQL을 추가한다.

/books/section[title='XML']/section[title='Basic Syntax']인 XQuery명령에서 필터들의 부모 엘리먼트명이 section으로 같아도 depth가 달라 다른 엘리먼트이므로 부모가 같지 않다.

부모가 같지 않다면 아래 표 24와 같이 부모시퀀스와 현재시퀀스를 증가하여 SQL을 추가한다.

마지막으로 limit [필터시퀀스 값]에 필터시퀀스의 값을 넣어 SQL을 추가하면 첫번째 sql은 완성된다.

두번째 SQL을 만드는 방법은 아래 표 25의 SQL이 디폴트 SQL이다.

SELECT P0.DOCID, XX.DEPTHID, XX.NODEID, XX.ATTRID, XX.STARTPOS, XX.ENDPOS, XX.TERM, XX.TERM2 FROM 엘리먼트테이블 P0, 엘리먼트테이블 XX, 엘리먼트테이블 E0 WHERE P0.DOCID = XX.DOCID AND E0.DOCID = 첫번째 쿼리의 결과값 AND E0.STARTPOS = 첫번째 쿼리의 결과값 AND E0.ENDPOS = 첫번째 쿼리의 결과값 AND P0.DOCID = E0.DOCID AND P0.STARTPOS >= E0.STARTPOS AND P0.ENDPOS <= E0.ENDPOS AND XX.STARTPOS >= P0.STARTPOS AND XX.ENDPOS <= P0.ENDPOS ......... ORDER BY P0.DOCID, XX.STARTPOS

전술한 바와 같은 방식으로 추출한 Path Class들에서 필터시퀀스의 이후 Path Class들을 가지고 From절과 where절을 추가하여 쿼리를 만들면 두번째 SQL이 완성된다.

위의 예를 간단한 예제로 해보겠다.

만약 /books/section[2][title='XML']의 XQuery구문이 엔진을 통해 파싱을 해서 넘어오면 필요한 Path Class를 추출해 낸다. 위와 같을 경우 /books/section[2]를 가지고 첫번째 SQL을 만들고 [title='XML']을 가지고 두번째 SQL을 만든다. 우선 첫번째 SQL을 만들어 보면 아래 표 26과 같다.

SELECT P0.DOCID, P0.DEPTHID, P0.NODEID, P0.ATTRID, P0.STARTPOS, P0.ENDPOS, P0.TERM, P0.TERM2 FROM 엘리먼트테이블 P0 WHERE ( ( P0.DEPTHID = 30001 AND P0.NODEID = 2 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') ) ) ORDER BY P0.DOCID, P0.STARTPOS limit 2 /* 필터시퀀스값 */

위의 쿼리는 기본쿼리에

section 의 Path Class의 정보인 아래 표 27의 쿼리를 추가했다.

( P0.DEPTHID = 30001 AND P0.NODEID = 2 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') )

그리고 또 제일 마지막에 아래 표 28과 같이 필터시퀀스를 추가하여 첫번째 쿼리를 완성한 것이다.

limit 2

두번째 SQL을 만들어 보면 아래 표 29와 같다.

SELECT P0.DOCID, XX.DEPTHID, XX.NODEID, XX.ATTRID, XX.STARTPOS, XX.ENDPOS, XX.TERM, XX.TERM2 FROM 엘리먼트테이블 P0, 엘리먼트테이블 XX, 엘리먼트테이블 E0, 엘리먼트테이블 F0 , 엘리먼트테이블 FP0 WHERE P0.DOCID = XX.DOCID AND E0.DOCID = 100 AND E0.STARTPOS = 11 AND E0.ENDPOS = 28 AND P0.DOCID = E0.DOCID AND P0.STARTPOS >= E0.STARTPOS AND P0.ENDPOS <= E0.ENDPOS AND XX.STARTPOS >= P0.STARTPOS AND XX.ENDPOS <= P0.ENDPOS AND P0.STARTPOS >= FP0.STARTPOS AND P0.ENDPOS <= FP0.ENDPOS AND P0.DOCID = F0.DOCID AND F0.DOCID = FP0.DOCID AND F0.STARTPOS >= FP0.STARTPOS AND F0.ENDPOS <= FP0.ENDPOS AND (( P0.DEPTHID = 30001 AND P0.NODEID = 2 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') ) AND (( FP0.DEPTHID = 30001 AND FP0.NODEID = 2 AND FP0.ATTRID =0 AND ( FP0.TERM is null OR FP0.TERM = '' ) AND F0.DEPTHID = 30002 AND F0.NODEID = 1 AND F0.ATTRID = 0 AND F0.TERM = 'XML' ) ) ) ORDER BY P0.DOCID, XX.STARTPOS

위의 쿼리는 기본쿼리에 필터 Expression 때문에 아래의 쿼리를 추가했는데 [title='XML']의 기준이 되는 테이블을 추가해야 하는데 없으므로 title의 부모정보를 P0으로 넣었다.

그리고 아래 표 30의 필터 Expression으로 F0와 FP0의 테이블과 WHERE조건을 추가하여 두번째 SQL이 완성된 것이다.

엘리먼트테이블 F0 , 엘리먼트테이블 FP0 ..... AND (( P0.DEPTHID = 30001 AND P0.NODEID = 2 AND P0.ATTRID = 0 AND (P0.TERM is null or P0.TERM = '') ) AND (( FP0.DEPTHID = 30001 AND FP0.NODEID = 2 AND FP0.ATTRID =0 AND ( FP0.TERM is null OR FP0.TERM = '' ) AND F0.DEPTHID = 30002 AND F0.NODEID = 1 AND F0.ATTRID = 0 AND F0.TERM = 'XML' ) ) )

도 12의 결과 SQL 문서 생성단계(S40)에서는 생성된 SQL을 가지고 엘리먼트테이블에서 문서번호(DOCID), 레벨(DEPTHID), 노드ID(NODEID), 속성ID(ATTRID), 시작위치(STARTPOS), 종료위치(ENDPOS), 내용1(TERM ), 내용2(TERM2)를 조회한 결과를 가지고 XML 문서로 변환한다.

노드ID가 0보다 크고 내용이 없을 때는 시작위치를 키로 값을 <엘리먼트명>로 저장을 하고 종료위치를 키로 </엘리먼트명>로 해쉬테이블에 저장한다. 노드ID가 0보다 크고 내용이 있을 때는 시작위치를 키로 값을 내용으로 해쉬테이블에 저장을 한다.

이 정보들이 해쉬에 저장될 때 현재의 레벨(DEPTHID)에 대해서도 다른 해쉬테이블에 같이 저장을 하는데 키는 현재의 레벨(DEPTHID)이고 값은 위의 이전의 해쉬테이블의 키인 위치값을 저장을 한다. 이 해쉬테이블은 속성테이블을 저장할 때 사용을 한다.

만약 속성ID가 0보다 클 때는 현재의 레벨(Depthid)을 가지고 해쉬테이블에 서 위치값을 얻어오고 그 위치값으로 해쉬테이블에서 값을 또 얻어온다. 그 값의 뒤에 속성이름 = 내용>을 추가한 후 위치를 키로 하고 값을 추가한 데이터로 하여 해쉬테이블에 다시 저장을 한다.

예를 들어 아래 표 31은 스키마테이블에 저장된 데이터이고,

30000,1,0,0,0,0,books, 30001,1,0,30000,1,0,title, 30001,2,0,30000,1,0,section, 30002,1,0,30001,2,0,title, 30002,2,0,30001,2,0,section, 30003,1,0,30002,2,0,title,

생성된 SQL을 엘리먼트테이블에서 실행한 결과가 아래 표 32와 같다면

1,30001,2,0,11,28,, 1,30002,1,0,12,15,, 1,30002,1,0,13,14,XML, 1,30002,2,0,16,21,, 1,30003,1,0,17,20,, 1,30003,1,0,18,19,Basic Syntax, 1,30002,2,0,22,27,, 1,30003,1,0,23,26,, 1,30003,1,0,24,25,XML and Semistructured Data,

XML로 변환이 되기 위한 데이터는 아래 표 33과 같이 왼쪽은 위치이고 오른쪽은 해당되는 문자열이 생긴다. 이 문자열을 연결하면 XML 문서가 생성된다.

11 <section> 12<title> 13 XML 14 15</title> 16 <section> 17<title> 18 Basic Syntax 19 20</title> 21</section> 22<section> 23<title> 24 XML and Semistructured Data 25 26</title> 27</section> 28 </section>

XML로 변환된 결과데이터는 XML 어댑터(3)로부터 XML 엔진(2)으로 리턴되며, XML로 변환된 데이터를 StringBuffer에 저장을 한 후 이 StringBuffer를 XML 엔진(2)에 리턴한다.

또한, 본 발명의 XML 엔진 시스템(1)은 XQuery 질의어가 아닌 일반 SQL 명령을 전달받아 실행하는 것도 가능하다. XML 엔진(2)은 SQL을 전달받고, 그 SQL을 가지고 실행을 한다.

여기서, SQL을 실행한 결과를 가지고 XML파일을 만드는데 JDBC의 메소드를 이용한다. JDBC의 메소드인 getColumnCount를 가지고 결과 칼럼숫자를 알아낸 다음 결과를 ROW단위로 <ROW>내용</ROW>로 하고 내용은 JDBC의 메소드인 getColumnName로 칼럼이름을 알아내어 <칼럼이름>결과내용</칼럼이름>으로 하고 앞에서 알아낸 칼럼숫자만큼 채우면 내용이 완성된다. 아래 표 34는 getColumnCount가 3인 최종 xml모습을 표시한 것이다.

<XQuery_Result> <ROW> <칼럼이름1>칼럼내용1</칼럼이름1> <칼럼이름2>칼럼내용2</칼럼이름2> <칼럼이름3>칼럼내용3</칼럼이름3> </ROW> <ROW> <칼럼이름1>칼럼내용1</칼럼이름1> <칼럼이름2>칼럼내용2</칼럼이름2> <칼럼이름3>칼럼내용3</칼럼이름3> </ROW> </XQuery_Result>

XML로 변환된 데이터는 StringBuffer에 저장을 한 후 이 StringBuffer를 XML 엔진(2)에 리턴을 한다.

상술한 바와 같이, 본 발명에 따른 XML DB 구축방법과 XQuery 엔진 시스템 및 그 수행방법의 실시예가 구성된다. 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 이것에 의해 한정되지 않으며 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 본 발명의 기술사상과 아래에 기재될 특허청구범위의 균등범위 내에서 다양한 수정 및 변형이 가능함은 물론이다.

본 발명에 따른 XML DB 구축방법은 다양한 문서 구조를 갖는 XML 문서 파일로부터 스키마정보 및 데이터정보를 추출하여 그 구조 및 경로정보를 고정된 테이블 구조를 갖는 XML DB에 저장시킴으로써 대용량의 XML 문서가 저장되더라도 바르고 효율적인 DB 접근성을 제공하는 효과가 있다.

또한, 본 발명의 XML 엔진 시스템 및 그 수행방법은 자연어에 가까운 XQuery 질의어를 XML DB에서 실행 가능한 SQL 명령으로 자동 변환함으로써 DB에 관하여 전문적인 지식이 없는 사용자라도 XQuery 명령을 통하여 XML DB로부터 원하는 XML 문서의 정보를 쉽고 빠르게 이용할 수 있는 효과를 제공한다.

Claims

XML 문서로부터 스키마 구조정보와 엘리먼트 경로정보를 추출하여 고정된 RDBMS 모델 기반의 XML DB를 구축하는 방법에 있어서,

(A1)XML 문서의 스트링 데이터를 파싱하여 개별 스키마 구조정보(레벨, 형제순서, 속성순서, 엘리먼트명, 부모레벨, 부모형제순서, 부모속성순서)를 스키마정보파일로 생성하는 단계;

(A2)개별 엘리먼트 경로정보(문서번호, 레벨, 형제순서, 속성순서, 상기 시작번호, 상기 종료번호, 데이터값)를 엘리먼트정보파일로 생성하는 단계;

(A3)상기 단계(A1)의 스키마정보파일로부터 상기 스키마 구조정보를 스키마테이블에 저장(insert)하는 단계; 및

(A4)상기 단계(A2)의 엘리먼트정보파일로부터 상기 엘리먼트 경로정보를 엘리먼트테이블(문서번호, 레벨, 형제순서, 속성순서, 시작번호, 종료번호, 데이터값)에 저장하는 단계

를 포함하여 이루어져, 상이한 구조의 복수개 XML 문서를 인덱싱 기법을 통하여 단일의 XML DB에 저장하는 것을 특징으로 하는 XML 데이터의 DB 구축방법.
제 1항에 있어서,

상기 단계(A1)는,

현재 엘리먼트가 동일 부모하에서 이전에 읽혀진 형제 엘리먼트와 레벨과 엘 리먼트값이 동일할 경우, 형제순서의 증가없이 다음 엘리먼트를 읽음으로써 처리속도를 향상시키고, 데이터량을 줄이는 것을 특징으로 하는 XML 데이터의 DB 구축방법.
제 1항 또는 제 2항에 있어서,

상기 단계(A1)는,

(A1-1)현재위치, 레벨 및 문서번호를 초기화하는 단계;

(A1-2)개별 엘리먼트를 하나씩 읽는 단계;

(A1-3)시작/종료 엘리먼트인지 판단하는 단계;

(A1-4)시작 엘리먼트일 경우, 상기 레벨을 1 증가하고, 부모노드 정보를 엘리먼트시퀀스 해쉬에 기록하고, 상기 스키마 구조정보를 상기 스키마정보파일에 저장하는 단계;

(A1-5)상기 엘리먼트의 속성 유무를 판단하는 단계;

(A1-6)속성이 존재하는 경우, 속성시퀀스 해쉬에 속정정보를 기록하는 단계;

(A1-7)종료 엘리먼트일 경우, 상기 레벨을 1 감소하는 단계; 및

(A1-9)상기 XML 문서의 끝을 만난 경우로 종료하는 단계

를 포함하여 이루어지는 것을 특징으로 하는 XML 데이터의 DB 구축방법.
제 1항에 있어서,

상기 단계(A2)는,

(A2-1)현재위치, 레벨 및 문서번호를 초기화하는 단계;

(A2-2)개별 엘리먼트를 하나씩 읽는 단계;

(A2-3)시작/종료/값 엘리먼트인지를 판단하는 단계;

(A2-4)시작 엘리먼트일 경우, 상기 현재위치 및 레벨을 1 증가하고, 상기 엘리먼트의 레벨정보를 레벨 해쉬에 기록하고, 상기 엘리먼트의 부모 레벨의 시작번호를 시작번호 해쉬에 기록하는 단계

(A2-5)상기 엘리먼트의 속성 유무를 판단하는 단계;

(A2-6)속성이 존재하는 경우, 상기 현재위치 및 레벨을 1 증가하고, 상기 엘리먼트의 레벨정보를 상기 레벨 해쉬에 기록하고, 상기 엘리먼트의 부모 레벨의 시작번호를 상기 시작번호 해쉬에 기록하고, 상기 엘리먼트 경로정보를 상기 엘리먼트정보파일에 저장하고, 상기 레벨을 1 감소하는 단계;

(A2-7)종료 엘리먼트일 경우, 상기 현재위치를 1증가하여 종료번호로 하고, 상기 엘리먼트 경로정보를 상기 엘리먼트정보파일에 저장하고, 상기 레벨을 1 감소하는 단계;

(A2-8)데이터 엘리먼트일 경우, 상기 현재위치를 1증가하여 시작번호로 하고, 상기 현재위치를 증가하여 종료번호로 하고, 상기 엘리먼트 경로정보를 상기 엘리먼트정보파일에 저장하는 단계; 및

(A2-9)상기 XML 문서의 끝을 만난 경우로 종료하는 단계

를 포함하여 이루어지는 것을 특징으로 하는 XML 데이터의 DB 구축방법.
XML 파서 명령, XQuery 명령 또는 일반 SQL 명령을 전달하고 그 처리결과를 리턴받는 XML 엔진;

상기 XML 엔진으로부터 상기 XML 파서 명령을 제공받아 파서 실행을 제어하고, 상기 XQuery 명령을 SQL 명령으로 변환하고, 상기 SQL 명령으로 XML DB를 검색하여 받은 결과를 결과 XML 문서로 변환하여 상기 XML 엔진으로 리턴하는 XML 어댑터;

상기 XML 어댑터에 의해 실행되고, 상기 XML 엔진이 지정하는 입력 XML 문서를 파싱하여 스키마정보와 엘리먼트정보를 생성하는 XML 파서; 및

상기 XML 어댑터로부터 상기 스키마정보와 엘리먼트정보의 데이터를 전달받아 저장하고, 상기 SQL 명령의 실행에 의하여 검색된 결과를 상기 XML 어댑터로 리턴하는 XML DB

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 시스템.
제 5항에 있어서,

상기 XML 어댑터는,

상기 입력 XML 문서에 대하여 상기 XML 파서를 실행하고 처리결과로서 스키마의 구조정보와 엘리먼트의 경로정보를 전달받고 상기 XML DB에 저장하는 파서 실행부;

XQuery 명령을 SQL 명령으로 변환하는 XQuery 변환부;

상기 SQL 명령을 실행하는 SQL 실행부;

상기 XML DB로부터 상기 SQL 명령의 실행 결과를 리턴받아 결과 XML 문서로 변환하는 결과 XML 문서 생성부;

상기 SQL 실행부 및 상기 결과 XML 문서 생성부가 상기 XML DB 사이에서 장치 인터페이스 처리를 하는 드라이버 관리부; 및

상기 XML 엔진의 명령에 대한 처리결과를 리턴하는 결과 리턴부

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 시스템.
제 5항에 있어서,

상기 XQuery 엔진은,

상기 XQuery 원시코드로부터 어휘분석을 통하여 토큰 문자열을 생성하는 스캐너부;

상기 스캐너부로부터 상기 토큰을 전달받고 구문분석을 통하여 구문트리를 생성하는 파서부; 및

상기 파서부로부터 상기 구문트리를 전달받고 어댑터 명령어를 생성하는 명령어 생성부

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 시스템.
XQuery 엔진 시스템에서의 수행방법에 있어서,

(1)XML 파서가 입력 XML 문서에 파싱을 수행하여 XML DB를 구축하는 단계;

(2)XML 어댑터가 XQuery 명령을 SQL 명령으로 변환하는 단계;

(3)XML 어댑터가 상기 SQL 명령을 상기 XML DB에서 실행하는 단계; 및

(4)상기 XML DB의 실행 결과를 결과 XML 문서로 생성하는 단계

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 수행방법.
제 8항에 있어서,

상기 단계(2)는,

(2-1)상기 XQuery 명령을 실행하는 단계;

(2-2)XML 엔진이 상기 XQuery 명령을 전달받는 단계;

(2-3)상기 XML 엔진이 XQuery 구문 파싱 후 어댑터 명령어로 변환하여 상기 XML 어댑터로 전달하는 단계;

(2-4)상기 XML 어댑터가 상기 어댑터 명령어로부터 Path Expression을 추출하는 단계;

(2-5)입력 XML 문서의 스키마정보를 해쉬 테이블에 저장하는 단계;

(2-6)상기 어댑터 명령어로부터 처리대상이 되는 Path Class를 추출하는 단계; 및

(2-7)상기 SQL 명령을 생성하는 단계

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 수행방법.
제 9항에 있어서,

상기 단계(2-3)는,

(2-3-1)스캐너에 의하여 XQuery 원시코드로부터 어휘분석을 수행하여 토큰을 생성하는 단계;

(2-3-2)파서에 의하여 상기 토큰으로부터 구문분석을 수행하여 구문트리를 생성하는 단계;

(2-3-3)어댑터 명령어 생성기에 의하여 상기 구문트리로부터 어댑터 명령어를 생성하는 단계; 및

(2-3-4)상기 어댑터 명령어를 상기 XML 어댑터로 전달하는 단계

를 포함하여 이루어지는 것을 특징으로 하는 XQuery 엔진 수행방법.