XML-QL : XML을 위한 질의 언어
20
0
0
전체 글
(2) 1.소개 W3 컨소시엄의 SGML 워킹 그룹(working group)은 XML(eXtensible Markup Language)라 불 리는 SGML의 부분 집합인 새로운 표준을 제안하였다. XML의 목표는 HTML에는 허용되 지 않는 SGML의 많은 이점들을 제공하고, 완전한 SGML보다 더 배우기 쉽고 사용하기 쉬 운 언어를 제공하는데 있다. 이 이점들은 문서의 태그와 속성의 임의적인 확장을 포함하고, 복잡한 구조를 가진 문서와 Document Type Definition(DTD)이라고 불리는 추가적인 문서구조 문법을 통하여 문서구조에 대한 검증을 지원한다. SGML로부터 물려받은 DTD는 어떤 엘 리먼트들이 나오고 그 엘리먼트들이 DTD를 뒷받침하는 XML문서에서 어떻게 삽입되는지 를 명기한다. XML에 대한 많은 어플리케이션들이 존재할 수 있는데, 이중 하나의 중요한 어플리케이션 은 웹에서 두개 또는 여러 데이터 소스들간의 전자데이터(EDI)의 교환이다. 이 문제는 많 은 비즈니스들이 그들의 데이터베이스를 액세스하고 관련 사업들과 조직들간에 데이터 교환 을 제공하기 위해 XML을 선택할 때에 점점 더 중요해진다. 이 문서에서 우리는 EDI에의 XML 어플리케이션에 초점을 맞출 것이다. 특히, 우리는 문서적 관점에 반대되는, XML문서 가 데이터 베이스가 되도록 그리고 DTD가 데이터베이스의 개요가 되도록 간주하는 XML 의 데이터베이스 적인 관점을 취할 것이다. XML의 이점중의 하나는 그것의 단순함에 기인한다. XML문서는 엘리먼트들의 연속이고, 특별한 규정이 없는 본문 그리고/ 또는 엘리먼트들의 각각의 구성이다. 단 이때에 하나의 제 약은 엘리먼트 태그들은 반드시 짝을 이루어야 하고(예를 들면, 각각<ADDRESS>는 </ADDRESS>와 짝을 이루어야 한다), 반드시 올바르게 중첩되어야 한다는 것이다. 짝을 가 지고 올바르게 삽입된 하나의 XML문서는 잘 구성된(well-formed) XML이다라고 불린다. XML안의 엘리먼트들은 객체지향적 이거나 객체관련 데이터베이스 안의 객체들로 생각할 수 있다. 예를 들면, 하나의 <PERSON>… </PERSON>는 PERSON(… ) 형태 클래스의 객체에 부합할 것이다. 중첩된 XML 엘리먼트는 객체의 필드에 부합한다. 예를 들어, <PERSON>안 의 <NAME>, <PHONE>, <ADDRESS>엘리먼트들은 PERSON객체의 NAME, PHONE, ADDRESS 필드들에 부합될 것이다. 이 단순성은 사용자들이 처음에 스키마를 정의하지 않고도 복잡한 구조를 가진 XML데이 터를 만들 수 있도록 한다. EDI 어플리케이션에서 이것은 데이터들의 스키마가 여러 번 나 올 수 있기 때문에 특별히 중요하다. 그러나, 이것은 XML데이터의 구조에 대한 어떤 명세 를 가질 수 있어서 유용한 경우이다. 특히, 데이터의 교환을 위한 그 자체의 존재론을 정의 하기 위해 사용자 공동체에게 유용한데, 이 같은 경우에는 DTD들이 데이터의 알려진 구조 를 명기하는 데 사용된다. DTD들은 객체 지향적이거나 객체관련 데이터베이스 안의 논리적 구조들과 비슷하지만, 그것들은 덜 제한적이면서 데이터 안에서 좀더 다양함을 제공한다. 예를 들면, DTD들은 선택적인 필드 부분과 여러 번 발생할 수 있는 부분에 대해 명세할 수 있으며, DTD들은 미리 정의된 참조(IDREF)의 형식을 필요로 하지 않는다. XML의 유연성은 많은 문서들이 HTML과 같이 좀 더 쉽고 수월하게 웹에서 교환되어질 수 있도록 한다. 분자에 대한 데이터의 교환을 위한 Chemical Markup Language와 은행들 사 이 또는 은행과 예금주 사이의 금전적 데이터의 교환을 위한 Open Financial Exchange를 포함 하는 수십 개의 XML 어플리케이션들이 이미 존재한다. 그러나, 많은 양의 XML데이터의 가용도에 대해서는 XML표준이 데이터를 언급하지 않는다는 몇몇 기술적인 질문을 드러내 고 있다. 특히, 많은 XML문서로부터 어떻게 데이터를 추출할 것인가라는 문제가 가장 큰 문제이다. 예를 들어, XML문서들의 이동 또는 질의들의 이동에 의해 어떻게 XML데이터가.
(3) 교환될 것인가? 이것과는 다르지만 관련된 존재론 (또는 DTD들)을 사용하는 사용자 공동체 사이에서 XML 데이터가 어떻게 교환될 거인가? 여러 XML소스들로부터 XML데이터가 어떻게 조직화될 것인가? 데이터의 추출, 변화, 그리고 통합은 모두가 이미 잘 알려진 데이터 베이스에서의 문제이 다. 그것들의 해결책은 종종 관련된(SQL)이나 객체지향적(QQL) 질의 언어에 의존한다. 이 질의 언어들은 XML에 즉시 적용하지 않는다. 왜냐하면, XML데이터는 전통적 관계에 있거 나 객체 지향적인 데이터와 다르기 때문이다. 그러나 XML데이터는 최근 연구 공동체에서 연구한 반 구조적 데이터 모델들과 매우 흡사하다. 몇몇 연구에서 질의 언어들이 설계되어 반 구조적 데이터에 제공되었다. 이 문서에서, 우리는 위의 질문들에 대한 해법으로 XML-QL이라 불리는 XML데이터를 위 한 질의어를 제안한다. XML-QL은 XML문서에서 데이터의 조각으로 추출되는 질의들을 표 현할 수 있다. 예를 들면, DTD들 사이에서 XML데이터를 맵핑할 수 있고, 다른 소스로부터 XML데이터를 통합할 수 있다. 이 문서를 통해서 우리는 data를 XML 데이터(data)로서가 아닌 데이터 베이스 또는 전자 문서 교환으로서의 용어로 사용한다. 우리는 XML-QL은 XML문서의 스타일과 레이아웃을 명기하기 위해 본질적으로 지향하는 XSL과 다르다는 것을 언급한다. 비록 XML-QL이 XSL 의 약간의 기능을 공유하지만, XML-QL은 조인과 총합(aggregate) 같은 더 많은 데이터 집약 적인 연산을 지원하고, 변환에 필요한 새로운 XML데이터의 구성 기능들을 추가로 지원한다. 우리는 XML에 대한 표준 질의어가 필수적으로 필요하다고 믿는다. 우리는 이 XML-QL을 XML에 대한 질의로서 제안한다. 이 제안은 이미 많은 공동체의 관심을 얻으며 만들어 졌다. 우리는 현재의 제안과 그것의 현제 작자의 그룹을, 광범위한 지원까지도 얻을 수 있는 언어 를 개발하기 위해 워킹그룹(working group)을 확립하는 시초로서 사용하는 것을 제안하고 있 다. 이 문서는 예제 질의들을 통해 XML-QL을 소개하고 있다. 이 예제들은 XML-QL이 XML 문서로부터 어떻게 데이터를 추출할 수 있는지, 그리고 어떻게 XML-QL을 이용하여 새로운 XML데이터를 생성할 수 있는 지를 보여준다. 우리는 그 다음에 XML-QL의 기본적인 데이 터 모델(data model)을 소개할 것이다. 모든 질의어들은 기본적인 데이터의 물리적인 표현으 로부터 발췌된 기본적인 데이터 모델을 가진다. 예를 들면, 관계형 질의어들은 관계들에서 그리고 객체 지향 질의어 들은 객체에 대하여 동작한다. 그리하여, XML의 정확한 데이터 모델을 정의할 필요가 있다. XML을 반 구조적 데이터의 변형이라 보는 것은 적합하다. 이 모델이 주어지면, 우리는 그 다음에 XML데이터의 변환과 통합 같은 XML-QL의 더욱 진보 된 특성들을 설명할 것이다. 마지막으로, 우리는 XML-QL의 전체적 문법을 제공할 것이다. XML-QL의 설계에서 우리는 반 구조적 데이터를 위한 질의어의 설계와 구현에 이미 존재하 던 연구를 적용하였다. [1],[2], 그리고[3]의 예제를 보라. 반 구조적 데이터상의 작업을 설명 한 튜토리얼은 [4] 와 [5]에서 찾을 수 있다.. 2.XML-QL의 예 우리는 예제들을 통해서 XML-QL을 소개할 것이다. 가장 간단한 XML-QL질의 들은 XML 문서로부터 데이터를 추출해 낸다. 우리의 XML입력 예제는 www.a.b.c/bib.xml에 있고, 그것 이 다음의 DTD를 따르는 bibliography 엔트리(entry)들을 포함한다고 가정한다..
(4) <!ELEMENT book (author+, title, publisher)> <!ATTLIST book year CDATA> <!ELEMENT article (author+, title, year?, (shortversion|longversion))> <!ATTLIST article type CDATA> <!ELEMENT publisher (name, address)> <!ELEMENT author (firstname?, lastname)> 이 DTD는 하나의book 엘리먼트(element)가 하나 또는 그 이상의author 엘리먼트, 하나의 title, 그리고 하나의publisher엘리먼트를 가지고, 하나의 year 어트리뷰트 (attribute)를 가지고 있다. Article 은 비슷하지만, 이것의 year엘리먼트는 선택적이고, publisher를 생략하고, 하나의 shortversion 또는 longversion 엘리먼트를 포함한다. Article은 또한 하나의type 어트리뷰트를 포함한다. publisher는 name 과 address 엘리먼트를 포함하고, author는 하나의 선택적인 firstname과 필 수적인 lastname을 가진다. 우리는 name, address, firstname, 그리고 lastname이 모두 문자열 값 인 CDATA라는 것을 알 수 있다. 패턴을 사용한 데이터 검색. XML-QL은 XML문서에서 데이터를 검색하기 위해 엘리먼트 패 턴(element patterns)를 사용한다. 이 예제는 www.a.b.c/bib.xml에의 xml문서에서 publisher가 Addison-Wesley인 책들의 모든 author를 산출한다. XML 데이터 소스를 나타내는 어떤 URI(uniform resource identifier)는 IN의 오른쪽에 나타날 것이다.. WHERE <book> <publisher><name>Addison-Wesley</name></publisher> <title> $t</title> <author> $a</author> </book> IN "www.a.b.c/bib.xml" CONSTRUCT $a 명백히, 이 질의는 하나의 <title>엘리먼트, 하나의 <author>엘리먼트, 그리고 <name>엘리먼 트가 Addison-Wesley인 <publisher>엘리먼트를 가지는 www.a.b.c/bib.xml에 있는 XML문서 안 의 모든 <book>인 엘리먼트와 일치한다. <book>과 그 하위 엘리먼트들이 매번 일치할 때 마 다 모든 title과 author쌍을 변수들 t와 a로 묶는다. 이 결과로서 a는 author들의 목록을 갖게 된다. 변수 이름들이 (Addison-Wesley같은) XML문서 안의 문자열 리터럴(literal)로 부터 그것 들을 구분하기 위해 $에 의해 선행된다는 것을 주의해라. 편의를 위해, 우리는 </element>를 </>로 줄인다. 이 생략은 우리가 태그들에 대해서 태그 의 변수들과 정규표현 들을 소개할 때, 바로 곧 있을 XML문법의 완화법이다. 따라서 위의 질의들은 다음처럼 쓰일 수도 있다... WHERE <book> <publisher><name>Addison-Wesley</></> <title> $t</> <author> $a</> </> IN "www.a.b.c/bib.xml" CONSTRUCT $a.
(5) XML 데이터의 생성. 위의 질의는 입력 문서로부터 모든 author(<firstname>, <lastname>의 쌍) 를 반환한다. 종종 이것은 질의 결과에 대하여 새로운 XML데이터 (즉, 입력 문서에 존재하 지 않았던 데이터)를 생성하는 데 유용하다. 다음의 질의는 <author>와 <title>모두를 반환하 고, 새로운 <result> 엘리먼트 안에 이들을 그룹으로 묶어 생성한다.: WHERE <book> <publisher><name>Addison-Wesley</></> <title> $t</> <author> $a</> </> IN "www.a.b.c/bib.xml" CONSTRUCT <result> <author> $a</> <title> $t</> </> 예를 들어, 다음의 XML데이터가 존재한다고 하자. <bib> <book year="1995"> <!-- A good introductory text --> <title> An Introduction to Database Systems </title> <author> <lastname> Date </lastname> </author> <publisher> <name> Addison-Wesley </name > </publisher> </book> <book year="1998"> <title> Foundation for Object/Relational Databases: The Third Manifesto </title> <author> <lastname> Date </lastname> </author> <author> <lastname> Darwen </lastname> </author> <publisher> <name> Addison-Wesley </name > </publisher> </book> </bib> 예제 데이터를 적용했을 때, 우리의 예제 질의는 다음과 같은 결과를 생성할 것이다. <result> <author> <lastname> Date </lastname> </author> <title> An Introduction to Database Systems </title> </result> <result> <author> <lastname> Date </lastname> </author> <title> Foundation for Object/Relational Databases: The Third Manifesto </title> </result> <result> <author> <lastname> Darwen </lastname> </author> <title> Foundation for Object/Relational Databases: The Third Manifesto </title> </result>.
(6) 중첩 질의를 통한 그룹핑. 위의 질의는 book의author를 그룹 짓지 않는다. 즉, 같은 book에서 의 서로 다른 author는 서로 다른 <result>엘리먼트에서 나타난다. book의 title에 의해 결과를 그룹 짓기 위해, 우리는 각각의 title에 하나의 결과를 생성하고, 모든 그것의 author의 목록 을 포함하는 중첩된 질의를 사용한다. WHERE <book > $p</> IN "www.a.b.c/bib.xml", <title > $t</>, <publisher><name>Addison-Wesley</>> IN $p CONSTRUCT <result> <title> $t </> WHERE <author> $a </> IN $p CONSTRUCT <author> $a</> </> <book>으로 시작하는 패턴은 중첩되지 않아서, 우리가 엘리먼트의 내용에 $를 묶을 수 있 다는 것을 주시해라. 한번 내용변수가 묶여 지면, 그것은 같은 WHERE안, 또는 중첩된 CONSTRUCT 표현 안의 IN의 오른쪽에 나타날 것이다. 엘리먼트 안의 내용을 그룹 짓는 것과 그룹으로 묶인 엘리먼트 안의 패턴을 매치하는 것 은 공통된 구절(idiom)이기 때문에, 우리는 본래의 중첩을 유지하는 문장 구성상의 생략법을 소개한다. 패턴의 뒤에 나오는 CONTENT_AS $p는 변수 $p에 매칭되는 엘리먼트의 내용을 묶는다. WHERE <book> <title> $t </> <publisher><name>Addison-Wesley </> </> </> CONTENT_AS $p IN "www.a.b.c/bib.xml" CONSTRUCT <result><title> $t </> WHERE <author> $a</> IN $p CONSTRUCT <author> $a</> </> 예제 데이터에서, 질의는 다음의 결과를 생성될 것이다.: <result> <title> An Introduction to Database Systems </title> <author> <lastname> Date </lastname> </author> </result> <result> <title> Foundation for Object/Relational Databases: The Third Manifesto </title> <author> <lastname> Date </lastname> </author> <author> <lastname> Darwen </lastname> </author> </result> value값을 통한 엘리먼트의 조인. XML-QL은 같은 값을 가지는 둘 또는 그 이상의 엘리먼트 를 매치함으로써 “조인(join)”을 표현할 수 있다. 예를 들면, 다음의 질의는 1995년 이후로.
(7) 쓰여진 book의 author를 최소한 하나이상을 가지는 모든 항목을 검색한다. 여기서, 우리는 author는 article과 book 모두에 같은 firstname과 lastname(변수 $f와 $l에 의해 표시되는)을 사 용한다는 것을 가정한다. WHERE <article> <author> <firstname> $f </> // firstname $f <lastname> $l </> // lastname $l </> </> CONTENT_AS $a IN "www.a.b.c/bib.xml" <book year=$y> <author> <firstname> $f </> // join on same firstname $f <lastname> $l </> // join on same lastname $l </> </> IN "www.a.b.c/bib.xml", y > 1995 CONSTRUCT <article> $a </> 위의 질의는 또 하나의 공통적인 구절을 사용한다: 첫번째 CONSTRUCT 표현은 입력 엘 리먼트 안에서 나타나는 같은 엘리먼트를 생성한다. 하나의 엘리먼트를 재창조하는 것을 피 하기 위해, 우리는 모든 선행하는 엘리먼트에 $e을 묶는 ELEMENT_AS $e 표현을 사용할 수 있다. WHERE <article> <author> <firstname> $f</> // firstname $f <lastname> $l</> // lastname $l </> </> ELEMENT_AS $e IN "www.a.b.c/bib.xml" ... CONSTRUCT $e. 3.XML의 데이터 모델 위의 예제 질의 들은 XML 데이터가 어떻게 모형화 되었는지 임의적인 추정을 할 수 있 게 한다. 예를 들면, 형제(sibling) 엘리먼트에 매치되는 패턴은 어떤 순서로도 나타날 수 있 다. 즉, 이 패턴 표현 : <author> <firstname> $f</> <lastname> $l</> </author> 은 다음과 동등하다: <author> <lastname> $l</> <firstname> $f</> </author> 데이터 모델(model)은 비록 형제 엘리먼트들이 XML문서에서 고정된 순서를 갖는다 해도.
(8) 정렬된 형제 엘리먼트들을 요구하지 않는다. 이러한 전제들이 데이터 모델에 의해 정식으로 정의된다. XML-QL 데이터 모델을 설명하기 위해, 예제의 book 엘리먼트들을 검토해 보라. 첫번째 레코드(recode)는 세 개의 엘리먼트(하나의 title, 하나의 author, 그리고 하나의 publisher)를 가지고 두 번째 레코드는 두개의 author를 가진다. 그러나 XML문서는 다음과 같이, 데이터 자신과는 관련 없는 추가적인 정보를 포함한다. 첫번째 book 엘리먼트의 시작에서의 주석. Title이 author보다 앞에 온다는 사실. 그리고, 모든 author에서 firstname이 lastname보다 앞에 온다는 사실 우리는 XML의 응용들이 데이터와 정보로 구별될 수 있다고 가정한다. 우리는 데이터에 필수적인 정보만을 표현하는 모델을 제안한다. 우리는 질의어의 의미와 효율을 가지고 해야 만 하는 이유의 절충안을 만들었다. 제안된 XML데이터 모델은 반 구조적 데이터 모델의 산포도이다. XML문서는 XML 그래 프(graph)에 의해 모델링 된다. 공식적인 정의는 다음과 같다. 정의. XML 데이터는 다음과 같이 구성되어있다. ?? 그래프, G는 각각의 정점에서 객체 확인자(OID)라 불리는 특정 문자열에 의해 표현된다. ?? G의 모서리들은 태그 확인자 엘리먼트로 레이블 된다. ?? G의 노드들은 어트리뷰트-값 쌍의 집합으로 레이블 된다. ?? G의 단말 노드들은 값(문자열)로 레이블 되고, ?? G는 루트라 불리는 구별된 노드를 갖는다. 예를 들면, 예제 데이터는 아래의 그래프에 의해 표현될 것이다. 어트리뷰트들은 모서리 레이블에 의해 표현되는 노드와 엘리먼트와 연결된다. 우리는 node와 object 용어를 교환 가 능하게 사용한다. 이때의 혼란을 줄이기 위해 객체 확인자(object identifier)는 생략한다.. XML graph for example XML book elements 이 모델은 같은 두 노드사이에 몇몇의 모서리를 허용하지만, 그것들은 반드시 특정한 레 이블을 가져야 한다: 다시 말해서, 우리는 같은 소스, 같은 목적지, 같은 레이블을 가지고 두개의 모서리를 접을 수 있다. Element Identity, IDs, and ID References.
(9) 엘리먼트의 공유를 제공하기 위해 XML은 하나의 엘리먼트에 결합되는 특정한 키를 허용 하는, type ID(종종 ID라 불리는) 어트리뷰트를 갖는다. IDREF 형식의 어트리뷰트는 지정키 로 다른 엘리먼트를 조사하기위한 엘리먼트를 허용하고, IDREF 형식의 하나는 다중 엘리먼 트로 간주될 것이다. 데이터 모델은 모든 다른 것들로부터 이 형태의 어트리뷰트들을 달리 다룬다. 예를 들어, 각각이 ID와 IDREF의 형태인 ID와 author 어트리뷰트를 가정해보라. <!ATTLIST person ID ID #REQUIRED> <!ATTLIST article author IDREFS #IMPLIED> 그러면, 아래의 XML 단락의 첫 엘리먼트는 두개의 <person>엘리먼트의 o123과 결합시켜서 author가 이들 person으로 간주되는 <article>엘리먼트를 정의한다.. o234키를. <person ID="o123"> <firstname>John</firstname> <lastname>Smith<lastname> </person> <person ID="o234"> ... </person> <article author="o123 o234"> <title> ... </title> <year> 1995 </year> </article> XML 그래프에서, 모든 노드는 특정한 객체 확인자 (OID)를 갖는데, 그것은 같은 엘리먼 트들로 결합된 ID 어트리뷰트이거나, ID 어트리뷰트가 없을 때에는 생성된 OID 이다. 엘리먼트는 IDREF와 IDREFS 어트리뷰트를 사용하여 다른 엘리먼트를 조사할 수 있다. 다른 모든 어트리뷰트와 달리., 노드들로 결합된 이름-값의 쌍인 IDREF 어트리뷰트는 참 조 하는 엘리먼트를 조회하는 엘리먼트로부터 모서리에 의해 표현된다; 이 모서리는 어트리 뷰트의 이름에 의해 레이블 된다. ID 어트리뷰트는 또한 특별하게 다루어진다: 그것들은 노드의 OID가 된다. 예를 들면, 위의 엘리먼트는 XML 그래프에 의해 표현된다..
(10) 위 그래프에서 IDREF 어트리뷰트가 지칭하는 엘리먼트와 엘리먼트가 하위 엘리먼트를 지 칭하는 위치가 같을 때에는 그 구별이 약간 모호하다. 이를 위하여 사용자들이 다음과 같이 모서리에 대한(a.k.a. “pointer chasing”)질의를 간단히 쓰는 것을 허용한다. WHERE <article><author><lastname> $n</></></> IN "abc.xml" 또한 XML 구문에 위치할 수 있고, 참조객체를 액세스하기위해 ID 값의 표현에 같이 쓰일 수 있다. 예를 들면, 다음의 질의는 모든 lastname와 person 엘리먼트의 ID 어트리뷰트 값과 author엘리먼트의 IDREF 어트리뷰트 값을 합친 title 쌍을 생성한다. WHERE <article author=$i> <title> </> ELEMENT_AS $t </>, <person ID=$i> <lastname> </> ELEMENT_AS $l </> CONSTRUCT <result> $t $l</> <title></> ELEMENT_AS $t 구문이 %t를 임의의 내용을 갖는 <title>엘리먼트에 묶는다는 것을 주목해라. <title/>의 엘리먼트 표현은 내용이 없는 <title> 엘리먼트와 매치한다. 스칼라 값. 오직 XML 그래프의 말단 노드에서만 스칼라 값을 가질 수 있고, 이것들은 하나의 값만을 갖는다. 그 결과, XML 단락: <title>A Trip to <titlepart> the Moon </titlepart></title> 는 데이터 모델에서 직접적으로 표현될 수 없다. 그러나 다음의 단락: <title><CDATA> A Trip to </CDATA><titlepart><CDATA> the Moon </CDATA> </titlepart></title> 는 XML 그래프로 나타날 수 있다.. 말단 노드의 값은 그것의 oid이다..
(11) 엘리먼트 순서. 지금까지 우리는 순서가 없는 XML 데이터 모델을 설명하였다. 이 선택은 데이터 모델, 질의언어를 명료하게 하고, 질의 처리기에 순서 독립적인 최적화를 허용한다. 사실, XML-QL은 두개의 구별되는 데이터 모델을 지원한다. 하나는 순서가 있는 것이고 하 나는 순서가 없는 것이다. 순서가 있는 XML 그래프는 순서가 없는 것과 유사하지만, 그것 의 후손에 전체 순서를 갖는 각각의 노드를 포함한다. 순서가 있는 데이터 모델에서는 XML-QL은 엘리먼트의 순서를 지원하는 첨가적인 구조물을 제공한다. 정렬된 모델은 질의 어가 좀더 복잡한 구문이고, 어쩌면 덜 효율적인 처리 일지도 모른다. 비록 순서가 없는 데 이터 모델의 구문이 더 간단하지만, 우리는 여전히 순서 없는 XML그래프가 문서 안에 표현 될 때, 순서를 선택해야만 한다. 우리는 이 대응관계에 대해 다음에 논하도록 한다. XML그래프를 XML데이터로 대응. XML그래프는 XML문서를 파싱하거나, 존재하는 그래프 를 질의하거나 변환함으로써 결과를 얻을 수 있다. 일반적으로, XML그래프는 XML 문서처 럼 특정한 표현을 가지지 못한다. 왜냐하면, 엘리먼트 순서가 지정되지 않았다(순서가 없는 모델에서), 즉, 우리는 각각의 그래프 노드의 모서리에 순서를 선택해야만 한다. 그리고 노드의 공유, 즉, 노드는 여러 입력 모서리를 가질 것이다. 두 경우는 모두 데이터 모델의 밖에서 다루어질 수 있고, 그래프가 XML 문서처럼 되었을 때 질의를 처리할 수 있다. 질의의 결과에 대해 주어진 DTD에서, XML 그래프는 DTD를 따 르는 XML데이터로써 표현되고, 그러므로 모든 엘리먼트는 정렬될 것이다. 우리는 여기서는 알고리즘의 문제를 다루지는 않는다.. 4.XML-QL의 보다 복잡한 예 다음의 예제는 XML-QL의 진보한 특징을 소개한다. 여기에서는 XML 그래프의 어떤 모서 리에도 올 수 있는 변수를 허용하는 태그변수 들, 그리고, XML 그래프를 통해 어떤 경로를 지정할 수 있는 정규 경로 표현(regular path expression) 이 있다. 태그 변수들 . XML-QL은 태그 변수들을 상용하여 엘리먼트 태그의 질의를 지원한다. 예를 들면, 다음의 질의는 Smith가 author이거나 editor인 1995년에 발간된 모든 publication들을 찾 는다.. WHERE <$p> <title> $t </title> <year>1995</> <$e> Smith </> </> IN "www.a.b.c/bib.xml", $e IN {author, editor} CONSTRUCT <$p> <title> $t </title> <$e> Smith </> </>.
(12) p는 어떤 상위단계 태그, 예를 들면, <book>,<article>, 등에 그룹으로 묶인 태그 변수이다. CONSTRUCT 절은 같은 태그이름을 갖는 결과를 생성한다는 것에 주목해라. e 역시 태그 변 수이다; 질의가 <author>이나 <editor>중에서 하나를 이것에 강제적으로 그룹 짓게 한다. 정규 경로 표현. XML데이터는 트리, 직접순환 그래프, 그리고 임의의 그래프 같은 중첩되 고 순환적인 구조를 가질 수 있다. 엘리먼트 공유는 위에서 설명된 것처럼 엘리먼트 ID와 IDREF들을 사용하여 지정될 수 있다. 어떤 구조를 질의하는 데에는 XML 엘리먼트에 대하여 경로에 대한 임의 순회(traversing arbitrary) 경로를 필요로 한다. 예를 들어, 재귀적인 엘리먼트 파트를 정의하는 다음의 DTD 를 고려해보자. <!ELEMENT part (name brand part*)> <!ELEMENT name CDATA> <!ELEMENT brand CDATA> 어떤 part 엘리먼트는 임의의 하위에 다른 중첩된 part 엘리먼트를 포함할 수 있다. 이런 구조를 질의하기 위해서, XML-QL은 임의의 하위에 있는 엘리먼트의 경로를 지정할 수 있는 정규 경로 표현 을 지원한다. 예를 들어, 다음의 질의는 r이 있는 곳의 중첩된 단계를 무시 하고, brand 엘리먼트가 “Ford”와 같은 엘리먼트를 포함하는 모든 part 엘리먼트의 이름을 생 성한다.. WHERE <part*> <name>$r</> <brand>Ford</> </> IN "www.a.b.c/bib.xml" CONSTRUCT <result>$r</> 여기서의 part* 는 정규 경로 표현 이고, part라고 레이블 된 모든 모서리의 순서와 일치한다. 다음의 패턴: <part*> <name>$r</> <brand>Ford</> </> 는 다음의 무궁무진한 피턴과 일치한다 <name>$r</> <brand>Ford</> <part> <name>$r</> <brand>Ford</> </> <part> <part> <name>$r</> <brand>Ford</> </> </> <part> <part> <part> <name>$r</> <brand>Ford</> </> </> </> . . . wildcard $는 아무 태그와도 일치하고, 태그가 허용되는 어느 곳에서도 나타날 수 있다. 예 를 들면, 다음의 질의는 위의 것 중 하나와 같다. 그러나, 단지 part 만이 아닌 아무 엘리먼 트도 일치한다. WHERE <$*> <name>$r</> <brand>Ford</> </> IN "www.a.b.c/bib.xml", CONSTRUCT <result>$r</> 우리는 *로 $*를 생략할 수 있다. 또한 .는 정규표현의 연결을 나타내고, 따라서 패턴은 그것이 얼마나 깊이 있는지에 상관 없이 오직 Ford의 값을 갖는 brand만을 찾는다. 다음과 같이 쓰인다..
(13) <*.brand>Ford</> *.brand 표기법은 파일 이름에서 유닉스의 wildcard를 연상시킨다. 그것은 “brand로 끝나는 모든 것”을 의미한다. XML-QL의 정규 경로 표현은 정규 표현에서 사용되는 것들과 비슷한 교대(|), 연결(.), 그 리고 Kleene-star(*) 연산자를 제공한다. 정규 경로 표현은 XML이 엘리먼트를 허용하는 어느 곳에서도 허용된다. 예를 들어, 다음의 질의는 <part>엘리먼트로 중첩된 어떤 순차를 고려하 여, 어떤 중첩된 <subpart>엘리먼트 또는 중첩된 <component>엘리먼트 안의 포함된 <piece> 엘리먼드를 생성한다.. WHERE <part+.(subpart|component.piece)>$r</> IN "www.a.b.c/parts.xml" CONSTRUCT <result> $r</> + 연산자는 “하나 이상”을 의미한다: part+ 는 part.part*와 같다. 태그 변수들과 정규 경로 표현들은 공통점을 갖지만 동일한 DTD가 아닌, 두개 이상의 XML데이터 소스에 적용될 수 있는 질의를 사용할 수 있게 해준다. 왜냐하면, 이런 표현들 은 여러 소스로부터 다양한 데이터의 형식을 다룰 수 있기 때문이다. XML 데이터의 변환. XML의 중요한 사용 중 하나는 XML데이터를 변환하는 것이다. 예를 들어, 우리는 하나의 DTD로부터 다른 것으로 데이터를 변환하기를 원할지도 모른다. 더 명 확히 하자면, bibliography DTD와 함께 우리는 다음과 같은 person을 정의하는 DTD를 갖는다 고 생각해보라. <!ELEMENT person (lastname, firstname, address?, phone?, publicationtitle*)> 우리는 bibliography DTD를 따르는 데이터를 person DTD를 따르는 데이터로 변형하기 위한 질의를 쓸 수 있다. 다음의 질의는 bibliography 데이터베이스로부터 author를 추출하여, 이들 은 person DTD를 따르는 <person>엘리먼트로 변형한다.. WHERE <$> <author> <firstname> $fn </> <lastname> $ln </> </> <title> $t </> </> IN "www.a.b.c/bib.xml", CONSTRUCT <person ID=PersonID($fn, $ln)> <firstname> $fn </> <lastname> $ln </> <publicationtitle> $t </> </> 이 질의는 객체 확인자 (OID)와 결과가 생성되고 묶여지는 것을 통제하기 위해 함수를 사 용한다. <person>이 생성될 때마다, 그것과 연결된 OID는 personID ($fn,$ln)이다. personID는 함수이다. 그리고, 그것의 목적은 $fn, $ln 의 모든 별개의 값에 대해 새로운 확인자를 생성 하는 것이다. 만약, 나중에 질의가 $fn 과 $ln을 다시 같은 이름에 묶는다면(예를 들어, 같은.
(14) author에 대한 다른 publication을 찾는다면), 그때는 질의는 또 다른 <person>을 생성하지 않 고, 존재하는 <person>엘리먼트에 정보를 첨가할 것이다. 따라서, 모든 author의 <publicationtitle>들은 같은 <person>엘리먼트에 묶일 것이다. <firstname>과 <lastname> 어트리 뷰트는 그것들이 같은 값에 도달하기 때문에 복제되지 않는다. 우리는 <phone>과 <address> 는 bibliography 데이터에 그것들을 가지고 있지 않기 때문에 생성할 수 없다. 여러 XML 소스로부터의 데이터 통합. XML-QL을 이용하여, 우리는 동시에 여러 소스들을 질의 할 수 있고, 그것들의 데이터의 통합된 것을 생성할 수 있다. 여기의 예제에서, 우리는 www.a.b.c/data.xml와 www.irs.gov/taxpayers.xml 의 소스를 질의 하여 name과 social-security number의 모든 쌍을 생성한다. 이 두개의 소스는 두개 모두의 표현에서 ssn에 묶인 socialsecurity number에 합쳐진다. 그 결과는 오직 처음 소스에서의 name엘리먼트와 두번째 소스에 서의 income엘리먼트를 모두 갖는 엘리먼트 들만을 포함한다.. WHERE <person> <name></> ELEMENT_AS $n <ssn> $ssn</> </> IN "www.a.b.c/data.xml", <taxpayer> <ssn> $ssn</> <income></> ELEMENT_AS $i </> IN "www.irs.gov/taxpayers.xml" CONSTRUCT <result> $n $i </> 선택적으로, 우리는 함수를 사용하여 두개의 단락으로 질의를 쓸 수 있다.. { WHERE <person> <name> </> ELEMENT_AS $n <ssn> $ssn </> </> IN "www.a.b.c/data.xml" CONSTRUCT <result ID=SSNID($ssn)> $n </> } { WHERE <taxpayer> <ssn> $ssn </> <income> </> ELEMENT_AS $i </> IN "www.irs.gov/taxpayers.xml" CONSTRUCT <result ID=SSNID($ssn)> $i </> } XML-QL 질의들은 블록들과 하위 블록들 안에 구조된다: 글자는 중괄호({ }) 안에 포함되 고, 그것들의 의미는 관계형 데이터 베이스의 세미조인과 같다고 생각하면 된다. 우리의 예 제에서는 루트 블록은 없고 두개의 하위 블록 만이 있다. 첫 번째 하위블록에서는, 모든 person의 이름이 생성된다. 각각의 결과는 person의 SSN에 의해 주어진 특정한 OID를 갖는 다. 두 번째 하위 블록에서는, income을 갖는 person이 생성된다. 이전에 생성된 OID에 매치 되는 곳마다 <income>은 새로운 <person>을 포함하는 것이 아니라 그 객체에 첨가될 것이다. 이 질의는 앞의 것과는 다르다: 이것은 앞의 질의와는 달리 taxpayer가 아닌 모든 person과.
(15) taxpayer를 포함한다. 이것이 www.a.b.c/data.xml와 www.irs.gov/taxpayers. xml의 outer join 이다. 질의 블록은 융통성 있고, 강력한 특징이다. 다음의 질의는 publication 데이터베이스의 1995년에 발간된 모든 title을 검색한다; 게다가, 그것은 journal article의 publication의 month와 book의 publisher를 검색한다. . WHERE <$e> <title> $t </> <year> 1995 </> </> CONTENT_A $p IN "www.a.b.c/bib.xml" CONSTRUCT <result ID=ResultID($p)> <title> $t </> </> { WHERE $e = "journal-paper", <month> $m </> IN $p CONSTRUCT <result ID=ResultID($p)> <month> $m </> </> } { WHERE $e = "book", <publisher>$q </> IN $p CONSTRUCT <result ID=ResultID($p)> <publisher>$q </> </> } 밖의 블록은 1995년의 모든 publication들을 검색하고, 그들의 title에 대한 result 엘리먼트 를 생성한다. 첫번째 안쪽 블록은 만약 e가 journal-paper 이고 month 태그를 갖는지를 확인 한다; 만약 그렇다면, 그것은 같은 publication에 month 엘리먼트를 덧붙인다(이것은 Skolem function에 의해 제어된다). 마지막으로, 두 번째 안쪽 블록은 e가 book인지, publisher를 갖는 지를 확인하고, 결과에 publisher 엘리먼트를 덧붙인다. 순서가 없는 데이터 모델에서는, XML-QL은 다음과 같이 확장된다. WHERE절 안의 패턴은 이제 정렬된 것처럼 해석된다. 예를 들어, 패턴 <a> <b> $x </b> <c> $y </c> </a> 는 다음의 XML데이터와 매치할 것이다: <a> <b> string1 </b> <c> string2 </c> </a> 그러나 다음과는 매치하지 않을 것이다: <a> <c> string2 </c> <b> string1 </b> </a> WHERE절에서 변수를 묶는 것은 이제 정렬된다. 위의 예제를 계속 사용하여, 만약 데이 터가: <a> <b> string1 </b> <c> string2 </c> <b> string3 </b> <c> string4 </c>.
(16) </a> 라면, 변수들은 다음의 순서로 묶일 것이다. $x $y string1 string2 string1 string4 string3 string4 (string3, string2는 유효하게 묶이지 않았음에 주의해라.) 데이터 그래프가 공유할 때 같이 좀더 복잡한 경우에는 이 노드들의 서로 다른 경로에 기인하여 서로 다른 노드 순서를 가지 는 노드 바인딩이 생길 수도 있다. XML-QL은 데이터 그래프를 처리하고, 깊이-우선 그래프 검색으로 통하여 이 vertex 들을 나열해 나간다. 변수의 그룹은 노드 숫자에 의해 순서를 갖 고, 처리할 때 복제되어 묶이는 것을 제거한다. 간단한 질의의 경우에는 이것은 입력 그래프 의 순서를 보존한다. XML-QL은 어떤 엘리먼트의 인덱스를 추출하는 순서 변수를 지원한다. 예를 들어, 다음의 패턴: <a> ... </>[$i] <$x> ... </>[$j] 는 $i 또는 $j 를 모서리의 전체 순서를 갖는 인덱스를 나타내는 0.1.2.. 등의 정수로 묶는 다. 예를 들어, 다음의 질의는 lastname이 firstname 앞에 오는 모든 person을 추출한다. WHERE <person> $p </> in "www.a.b.c/people.xml", <firstname> $x </>[$i] in $p, <lastname> $y </>[$j] in $p, $j < $i CONSTRUCT <person> $p </> 선택적인 ORDER-BY 절을 통하여 결과물의 엘리먼트 정렬을 지정한다. 예를 들어, 다음 의 질의는 year, month의 순서로 publication을 추출하고, 같은 year/mounth 의 publication은 원 래 문서의 순서대로 정렬한다. WHERE <pub> &p </> in "www.a.b.c/bib.xml", <title> $t </> in $p, <year> $y </> in $p <month> $z </> in $p ORDER-BY $y,$z CONSTRUCT $t 좀더 복잡한 예제로, 다음의 질의는 publication안의 모든 author의 순서를 뒤바꾼다. WHERE <pub> $p </> in "www.a.b.c/bib.xml" CONSTRUCT <pub> WHERE <author> $a </>[$i] in $p ORDER-BY $i DESCENDING CONSTRUCT <author> $a </>.
(17) WHERE <$e> $v </> in $p, $e != "author" CONSTRUCT <$e> $v </> </pub> 데이터 안에 질의 삽입. XML-QL은 XML에 끼워 넣어질 수 있다. 예를 들어, 다음의 질의 는 두개의 구별되는 부분을 생성한다: article 과 book.. <result> <articles> WHERE <article< <title> $t </> <year> $y </> </> in "www.a.b.c/bib.xml", $y > 1995 CONSTRUCT <title> $t </> </> <books> WHERE <book< <title> $t </> <year> $y </> </> in "www.a.b.c/bib.xml", $y > 1995 CONSTRUCT <title> $t </> </> </> 함수 정의와 DTD들. 다음의 코드는 두개의 입력 XML 문서를 갖는 함수를 정의한다.. FUNCTION findDeclaredIncomes($Taxpayers, $Employees) WHERE <taxpayer> <ssn> $s </> <income> $x </> </> IN $Taxpayers, <employee> <ssn> $s </> <name> $n </> </> IN $Employees CONSTRUCT <result> <name> $n </> <income> $x </> </> END 이 함수는 다음과 같이 나타날 수 있다. findDelcaredIncomes ("www.irs.gov/taxpayers.xml", www.a.b.c/employees.xml) 좀더 복잡한 상황은 파라미터에 대한 DTD에 관련된다. 함수는 다음과 같이 쓰일 수 있 다: FUNCTION findDeclaredIncomes($Taxpayers:"www.irs.gov/tp.dtd", $Employees:"www.employees. org/employees.dtd"):"www.my.site.com/myresult.dtd" WHERE ... CONSTRUCT ....
(18) 질의 처리기는 각각 “tp.dtd”와 “employees.dtd”를 따르는 주어진 입력에 대해 myresult.dtd” 를 따르는 결과를 생성하려고 (a)컴파일 할 때 검사할 것이고, 각각 “tp.dtd”와 “employees.dtd”를 따르는 입력문서를 (b)실행할 때 검사할 것이다.. 5. 확장과 많은 문제점 다음의 특징들은 이 문서의 현재 버전에는 포함되지 않지만, 미래의 버전에 계획되어있다. 엔터티 . 우리는 엔터티 참조를 승인 할 것이다. 예를 들면, XML-QL 질의 안에서의 &M 같 은 것이다. 엔터티는 DTD 안에 정의되어 있다. 예를 들어, 엔터티 M은 문자열 값 “Mary”를 갖는다는 것은 다음과 같이 정의한다. <ENTITY %M “Mary”> 사용자 -정의 술어. 사용자-정의 술어는 사용자들이 엘리먼트와 태그 값에 자바나 펄 같은 확 장 언어로 쓰인 것을 임의로 술어를 적용할 수 있도록 허용한다. 문자열 정규 표현. 다음의 질의는 lastname이 정규 표현식 ‘Fern*’와 일치하고 address가 ATTAddress에 의해 정의된 확장 술어를 만족하는 firstname 이 엔터티 M을 대체한 택스트와 같은 모든 person을 생성한다. WHERE <person> <firstname>&M</> <lastname>’Fern*’</> <address>$a</> </> ELEMENT_AS $x in abc.xml, ATTAddress($a) CONSRUCT $x 네임 스페이스. 이것은 XML 네임 스페이스 접두사에 의해 한정되는 태그 값을 허용한다. XML 네임 스페이스는 여러 스키마들에 의해 정의된 구조를 갖는 데이트의 생성을 지원한 다. 예를 들어, address가 하나는 US, 하나는 Europe 등등의 여러 DTD들에 의해 정의될 수 있다고 가정해보자. 우리는 엘리먼트 이름을 그것이 정의된 네임 스페이스에 의해서 알맞게 할 수 있다. 이 질의는 오직 US 네임 스페이스 안에 있는 address를 갖는 person과 일치한다. WHERE <person> <lastname>’Fern*’</> <US:address>$a</> </> ELEMENT_AS $x in abc.xml, ATTAddress($a) CONSTRUCT $x 총합. 우리는 SQL에서 제공되는 다음과 같은 총합을 지원하기를 기대한다. 예를 들어, 다음 의 질의는 각각의 publisher에 대한 lowest-price와 highest-price를 검색한다. WHERE <book>.
(19) <publisher></> ELEMENT_AS $p <price>$x</> </> GROUP-BY $p CONSTRUCT <result-ID=f($p)> $sp <lowest-price>$min($x)</> <highest-price>$max($x)</> </> 세미조인. 하위 블록들은 세미조인의 제한된 형식만을 제공한다. 좀더 일반적인 세미조인 구 조는 CONSTRUCT 부분에서 선택적인 구성요소를 갖는 WHERE절의 선택적 부분을 연결할 것이다: 이것은 최근에 WHERE-CONSTRUCT 질의에 중첩되거나 하위 블록과 함수들로 인 해 덜 복잡하게 표현될 수 있다. XML 문법. 어떤 어플리케이션들은 XML 프로그램을 데이터로써 처리할 필요가 있어서, XML-QL 질의를 XML문서처럼 인코딩 함으로써 이득이 될 수도 있다. 다른 XML관련 표준 들은 이미 그것들이 이루어졌다(예를 들어, XML Data, XSL). 우리는 이것들을 XML-QL의 설 계에 대한 수직적 노력이라고 볼 수 있다. 다른 XML관련 표준에 대한 확장. RDF(Resource Description), XPointer, XML-Link 등.. 6. 요약 XML 데이터가 HTML 문서처럼 널리 쓰이게 될 것이란 기대에, 우리는 XML데이터의 내 용과 그것의 구조를 모두 질의할 수 있는 엔진에 대한 요구가 증가될 것이라고 예상한다. 우리는 또한 XML데이터가 웹상에서 교환하는 전자 데이터와 필요한 존재론 사이의 데이터 의 변환에 주요 수단이 될 것이라고 예상한다. XML-QL은 질의, 구조, 변환, 그리고 XML데이터의 통합을 지원한다. XML데이터는 데이 터 베이스 연구 공동체에서 비정규적이거나 급히 전개된 데이터 소스에 대한 데이터 모델로 서 제안된 반구조적 데이터와 매우 흡사하다. 우리는 반구조적 데이터에 대한 다른 질의어 (UnQL 그리고 Studel)에 대한 지난 경험에 기초하여 XML-QL을 설계했다. 우리는 XML-QL 에 대한 해석기를 실행해 왔고, 최근에 언어를 가지고 시험하고 있다.. 7.XML-QL에 대한 문법 노트 문법은 언어가 발전되는 것처럼 여전히 개발되고 있고, 이 문서의 현재 버전에서는 완 성되지 않았다. 종료 기호는 각괄호에 나타나고 그것의 어휘적 구조는 명기되지 않았다.. XML-QL Grammar XML-QL ::= (Function | Query) <EOF> Function ::= 'FUNCTION' <FUN-ID> '(' (<VAR>(':' <DTD>)?)* ')' (':' <DTD>)?.
(20) Query 'END' Query ::= Element | Literal | <VAR> | QueryBlock Element ::= StartTag Query EndTag StartTag ::= '<'(<ID>|<VAR>) SkolemID? Attribute* '>' SkolemID ::= <ID> '(' <VAR> (',' <VAR>)* ')' Attribute ::= <ID> '=' ('"' <STRING> '"' | <VAR> ) EndTag ::= '<' / <ID>? '>' Literal ::= <STRING> QueryBlock ::= Where Construct ('{' QueryBlock '}')* Where ::= 'WHERE' Condition (',' Condition)* Construct ::= OrderedBy? 'CONSTRUCT' Query Condition ::= Pattern BindingAs* 'IN' DataSource | Predicate Pattern ::= StartTagPattern Pattern* EndTag StartTagPattern ::= '<' RegularExpression Attribute* '>' RegularExpression ::= RegularExpression '*' | RegularExpression '+' | RegularExpression '.' RegularExpression | RegularExpression '|' RegularExpression | <VAR> | <ID> BindingAs ::= 'ELEMENT_AS' <VAR> | 'CONTENT_AS' <VAR> Predicate ::= Expression OpRel Expression Expression ::= <VAR> | <CONSTANT> OpRel ::= '<' | '<=' | '>' | '>=' | '=' | '!=' OrderedBy ::= 'ORDERED-BY' <VAR>+ DataSource ::= <VAR> | <URI> | <FUN-ID>(DataSource (',' DataSource)*).
(21)
관련 문서
예를 들어 독일이나 일본 같은 나라는 상품수지 가 큰 규모의 흑자를 나타내는 대신 서비스수지 는 계속 적자가 이어지고 있다... 스, 그리스 등은 상품수지는 적자기조를 지속하
