Oracle XML DB 11g에서 복잡한 XML 데이터 관리하기

지난 몇 년 동안 XML은 데이터 전송을 위한 새로운 표준으로 각광 받아 왔으며, 기업의 XML 기반 솔루션 도입 사례가 증가하면서 그 영향력 또한 증가하고 있습니다. 전체 데이터 전송 작업에 XML 표준을 적용하는 기업의 사례가 늘고 있으며, 이로 인해 사용되는 XML 포맷 또한 복잡해지고 있습니다. 이 과정에서 XML 포맷 내에 여러 개의 네임스페이스, 수천 개의 엘리먼트, 재귀적 정의 등이 사용되기도 합니다. 이러한 포맷을 통해 생성된 XML 문서의 규모와 복잡성 역시 증가하고 있으며, 따라서 컨텐트의 관리가 한층 까다로운 과제로 부각되고 있습니다. 하지만 이러한 문제를 해결하는데 도움이 될만한 정보는 부족한 것이 현실입니다.

본 문서에서는 Oracle Database 11g에 포함된 XML DB 기능을 이용하여 복잡한 XML 컨텐트를 관리하는 방법, 그리고 Oracle XML DB가 다른 상용 ETL 제품과 비교했을 때 제공하는 이점에 대해 설명하고 있습니다. 본 문서에서 설명되는 XML 스키마 예제는 아래와 같은 내용을 포함하고 있습니다:

 •  복잡한 XML 스키마의 등록
 •  데이터베이스에 XML 파일을 삽입
 •  관계형 쿼리를 통해 XML 데이터를 조회
 •  XML 스키마 수정을 위한 In-Place Evolution 활용

그 밖에도, Oracle XML DB 솔루션의 성능과 처리 속도를 극대화하기 위한 전략과 복잡한 XML 포맷의 실제 활용 방안 등에 대한 설명이 제공됩니다.

Oracle XML DB 배경 정보

Oracle XML DB는 XML 컨텐트의 저장, 처리, 인출을 위한 강력한 툴로 Oracle Database에 기본 포함된 형태로 제공됩니다. Oracle XML DB는 다양한 XML 포맷에 수반되는 개별적인 요구 사항에 대응하기 위해 비구조형(structured), 바이너리(binary), 구조형(structured) 등의 여러 가지 저장 옵션을 제공합니다.

 •  비구조형 저장 방식(CLOB, character large object). 전체 문서를 하나의 오브젝트로 취급하여 데이터베이스에 저장하는 방식으로, 데이터의 INSERT 작업 시 성능이 가장 뛰어나다는 이점을 제공합니다. 하지만 다른 방식에 비해 저장 효율성이 떨어질 뿐 아니라 관계형 쿼리에 의한 조회 시 가장 낮은 성능을 보인다는 단점이 있습니다. 관계형 접근이 요구되는 환경에서는 크고 복잡한 XML 문서를 비구조형 옵션으로 저장하는 것은 결코 바람직한 대안이 될 수 없습니다. 비구조형 저장 방식은 디스크 공간에 여유가 많고 문서를 원본 포맷 그대로 저장하고자 하는 경우에 주로 사용됩니다.

 •  바이너리 저장 방식. Oracle Database 11g에 새로 추가된 옵션으로, XML 데이터를 위한 파싱 과정을 완료한 바이너리 포맷으로 데이터를 저장합니다. 이 옵션은 XML 스키마와 기본 호환하며 비구조형 저장 방식에 비해 디스크 공간 효율성과 쿼리 성능이 뛰어나다는 장점을 제공합니다. 바이너리 저장 방식은 비구조형 옵션과 비교가 어려울 정도로 개선된 성능을 제공하지만 구조형 저장 방식의 성능에는 미치지 못합니다. 바이너리 저장 방식은 관계형 접근의 성능을 일정 수준 보장할 수 있다고 판단되는 경우 효과적인 대안이 됩니다. 바이너리 저장 옵션은 그 활용이 매우 편리하므로 구조형 저장 옵션을 고려하기 전에 먼저 대안으로 생각해 볼 필요가 있습니다.

 •  구조형 저장 방식. 스키마 기반(schema-based) 저장 방식이라고도 불리는 이 옵션은 오브젝트-관계형 모델을 사용하여 데이터베이스에 XML 문서를 저장합니다. 구조형 저장 방식은 디스크 공간 효율성, 관계형 쿼리 성능의 측면에서 가장 뛰어나다는 이점을 갖습니다. 또 한편으로 파일의 INSERT 작업에서 높은 오버헤드를 수반하며 스키마 등록 과정에서 추가적인 준비 과정이 필요하다는 문제가 있습니다. 구조형 저장 방식은 최적화된 관계형 쿼리 성능을 구현하고자 하는 경우에 최적의 대안이 됩니다. 특히 매우 크고 복잡한 파일을 관계형 쿼리를 통해 효율적으로 처리하고자 하는 경우에 적합합니다.

XML 문서의 크기와 복잡성에 대한 인식은 기업 환경에 따라 크게 달라집니다. OLTP 데이터베이스에서 XML을 이용하여 EDI(electronic data interchange) 환경을 구현한 경우라면 파일의 라인 수가 수천 개 정도만 되어도 그 크기가 아주 큰 것으로 간주됩니다. 반면, 기가바이트 단위의 XML 문서를 주기적으로 처리하는 수 테라바이트급의 데이터 웨어하우스 환경에서는 라인 수가 수백만 개 정도는 되어야 큰 파일이라 할 수 있을 것입니다. XML 문서의 복잡성을 판단할 때에도 같은 개념이 적용됩니다.

본 문서에서는 문서가 다음과 같은 속성을 가질 때 "복잡한" 것으로 간주하고 있습니다.

 •  싱글 루트(single-rooted) 파일에 여러 개의 네임스페이스를 가짐
 •  검증 과정에서 다양한 옵션을 적용할 수 있도록 유연한 XML 정의를 허용함.
 •  재귀적 또는 순환적 참조를 가짐.
 •  정적이지 않은 XML 스키마를 포함함.

본 문서에서는 20MB 이상의 크기를 갖는 싱글-루트 XML 문서 파일을 "큰" 파일로 간주합니다. 이렇게 정의된 속성은 엔터프라이즈 솔루션이 요구하는 확장성, 관리성 등의 고려 사항에 영향을 미칩니다.

최적의 저장 방식을 선택하기 위한 황금률은 따로 존재하지 않습니다. 파일 구조, 성능 목표, 사용 가능한 리소스, 예상 데이터 량 등에 따라 최적의 대안이 달라질 수 있습니다. 어떤 저장 방식이 가장 좋을 것인지 판단하기 어렵다면 여러 가지 포맷을 적용해 가면서 최적의 대안을 확인하는 방법이 바람직합니다. 일반적으로 문서의 크기가 크고 관계형 쿼리가 실행되는 환경에서는 성능, 리소스의 측면에서 비구조형 저장 방식이 좋은 대안이 되기 어렵습니다. 바이너리 XML은 비즈니스 관점에서 쿼리 성능을 일정 수준 보장할 수 있다고 판단되는 경우, 또는 유지 보수에 수반되는 시간을 최대한 단축하고자 하는 경우에 적합합니다. 반면 관계형 쿼리의 성능이 가장 주된 관심사이고 XML 문서에 신속하게 접근해야 하는 경우라면 구조형 저장 방식이 최상의 대안이 될 가능성이 높습니다.

구조형 스토리지를 이용한 처리 속도의 극대화

구조형 저장 방식은 파일 INSERT 작업에 많은 오버헤드를 수반합니다. 하지만 큰 문서를 여러 개의 파일로 분할함으로써 오버헤드를 절감하는 것이 가능합니다. 예를 들어 700MB의 싱글-루트 XML 파일을, 올바른 XML 스키마를 갖는 10개의 작은 파일로 분할할 수 있습니다. 70MB 파일 10개를 처리하는 것이 700MB 파일 1개를 처리하는 것보다 성능 면에서 유리합니다. 작업의 동시성 레벨은 데이터베이스의 프로세싱 파워에 의해 결정됩니다. 이러한 방법으로 데이터베이스 동시성을 개선하고 처리 속도를 극대화할 수 있습니다.

Oracle XML DB를 사용할 때 고려해야 할 또 한 가지 사항으로, 하나의 XML 파일을 처리하는 속도는 개별 CPU 속도에 의해 제약된다는 점을 들 수 있습니다. 다시 말해, 프로세서를 여러 개 장착한다 해도 단일 문서의 처리 속도를 개선하는 데에는 도움이 되지 않습니다. 구조형 저장 방식으로 복잡한 싱글-루트 700MB 문서를 처리하는 경우를 생각해 봅시다. 1.35GHz 프로세서를 이용하여 이 문서를 처리하는 시간은 약 10분 정도 걸립니다. 데이터베이스의 CPU 수가 12개이든 72개이든 이 수치는 달라지지 않습니다. 단일 XML 문서의 처리 속도를 개선하려면 더 높은 성능의 CPU를 사용해야 합니다. 예를 들어 3.4GHz 프로세서를 사용한다면 처리 속도가 4분으로 단축될 수 있을 것입니다. 이에 반해, 여러 개의 XML 파일을 처리해야 하는 경우에는 여러 개의 프로세서를 사용하여 INSERT 작업의 동시성을 개선하고 처리 속도를 크게 향상시킬 수 있습니다. 예를 들어 700MB 파일이 10개의 70MB 문서로 분할되어 있다면, 1.35GHz 프로세서를 장착한 데이터베이스에서 1분 이내로 처리 시간을 단축할 수 있습니다. CPU의 수가 충분하다면 10개의 문서를 데이터베이스 내에서 동시에 처리할 수도 있을 것입니다.

하지만 그 결과를 정확하게 예측하는 것은 불가능합니다. 데이터베이스의 성능은 운영 체제, 프로세싱 파워, 메모리, 스키마 정의 등 여러 가지 요인에 따라 달라질 수 있기 때문입니다. 주어진 환경의 성능을 최적화하기 위한 최선의 방안은 여러 가지 전략을 구현해 보면서 그 장단점을 직접 비교해 보는 것입니다.

Oracle XML DB와 상용 패키지 제품의 비교

파일의 데이터를 데이터베이스로 가져 오기 위한 ETL(extract, transform, load) 툴이 다양하게 출시되어 있습니다. 이러한 툴들은 일반적으로 드래그-앤-드롭 기능을 이용한 단순화된 프론트엔드 인터페이스를 통해 내부 프로세스의 복잡성을 숨길 수 있도록 구현됩니다. ETL 툴에서 XML 로드 작업을 생성하는 과정에서는 추출 대상 필드를 정의하는 작업이 필요합니다. XPath가 올바르게 정의되지 않은 경우 문서로부터 데이터가 제대로 수집되지 않을 것입니다. 복잡한 XML 문서 환경에서, Oracle XML DB는 문서에 대한 데이터베이스 중심형 뷰를 제공하고 각 문서를 오브젝트-관계형 모델로 전환하여 보여 준다는 이점을 제공합니다. 파일이 데이터베이스 내에 성공적으로 로드되면, 별도의 파싱 과정을 거치지 않고도 데이터에 즉각적으로 접근할 수 있습니다.

Oracle XML DB의 또 다른 장점으로, 이 기능이 Oracle Database에 기본 포함되어 있으며 별도의 라이센싱을 요구하지 않는다는 점을 들 수 있습니다. 하지만 라이센싱 비용을 추가로 부담하는 것이 문제가 되지 않는 경우라면 상용 ETL 패키지 대신 굳이 Oracle XML DB를 사용할 필요가 있을까요? 이 질문에 답변하기 위해서는, 먼저 Oracle XML DB가 매우 복잡한 형태의 XML 문서에 수반되는 요구 사항을 어떻게 해결하고 있는지 이해할 필요가 있습니다.

복잡한 XML 컨텐트의 처리 문제

XML 컨텐트가 유연하고, 지속적으로 변화하고, 재귀적으로 정의된 매우 큰 문서로 구성되어 있는 경우 개발자는 여러 가지 문제에 부딪힐 수 밖에 없습니다. 복잡한 XML 문서에서는 XML 스키마가 매우 크고 높은 수준의 유연성이 요구되는 경우가 많습니다. 따라서 업계 표준을 준수하는 동시에 기업 내부의 요구 사항을 반영하기 위해서는 유연한 XML 스키마가 반드시 필요합니다.

세 곳의 기업에서 동일한 XML 스키마를 표준으로 채택한 경우를 생각해 봅시다. 이 XML 스키마는 공유/표준 엘리먼트 이외에도 각 기업이 내부적으로 정의한 엘리먼트가 함께 포함되어 있어야 합니다. 이러한 요구 사항을 지원하기 위해서는 다양한 형태의 엘리먼트를 참조하는 제너릭 컨테이너 엘리먼트를 이용하여 유연성을 극대화해야 합니다. 그 결과로, 전혀 다른 엘리먼트를 갖는 문서들이 동일한 XML 스키마 내에서 사용될 수 있어야 합니다. 개발자의 관점에서 볼 때, 이러한 유연성은 XML 파서(parser)의 개발을 어렵게 합니다. 어떤 엘리먼트가 사용될지 예측하기가 어렵기 때문입니다. COTS ETL 툴과 커스텀 파서에는 데이터 추출을 위한 구체적인 XPath가 명시되어야 하며, 따라서 문서 내의 모든 데이터를 캡처하기 위해서는 가능한 모든 XPath가 확인되어야 합니다. 사용 가능한 XPath의 종류가 엄청나게 많음을 감안할 때 이는 매우 비현실적인 솔루션이 될 수 밖에 없습니다. 그 뿐 아니라 스키마에 재귀적/순환적 참조가 존재한다면 그 수는 무한대로 증가할 것입니다. 캡처되지 않은 데이터가 감지되는 경우 이를 해결하기 위한 유일한 방안은 전체 파일을 다시 파싱하는 것입니다.

아래와 같은 XML 스키마를 고려해 봅시다(스키마에는 순환적 참조가 사용되고 있으며, 제너릭 엘리먼트를 이용하여 유연성을 보장하고 있습니다):


크게보기

이 XML 스키마는 세일즈/인벤토리 데이터의 전송을 위한 업계 표준으로 사용될 수 있습니다. standardData.xsd 네임스페이스에서 childContainer 엘리먼트와 companySpecificContainer 엘리먼트가 셀프-참조(self-referencing) 옵션을 제공하고 있음을 주목하시기 바랍니다. 이러한 설계를 통해 개별 기업들이 부모/자식 관계를 이용하여 데이터의 세분화 수준을 결정하도록 할 수 있습니다. 또 각각의 기업은 인벤토리, 세일즈 데이터 중 하나 또는 두 가지 모두를 포함시킬 수 있습니다. 또 각 기업의 요구 사항에 따라 상점, 제품, 세일즈 정보를 0개에서 무한대까지 포함시킬 수 있는 유연성이 제공됩니다.

ABC라는 회사가 여러 상점의 인벤토리/세일즈 데이터를 포함시키고자 하는 경우를 가정해 봅시다. 이를 위해 CompanySpecificContainer 엘리먼트들을 사용하여 각 상점(부모)을 정의하고, CompanySpecificContainer 엘리먼트들을 사용하여 각 상점의 제품(자식)을 정의할 수 있습니다. ABC 회사가 사용할 수 있는 문서의 예가 아래와 같습니다:


크게보기

이에 반해 XYZ라는 기업은 단 하나의 상점만을 갖고 있으며, 파일 내에 표준적인 세일즈 데이터만을 포함시키고자 합니다. 이 경우 childContainer 엘리먼트를 제외하고 salesInformation 엘리먼트들만을 포함시킬 수 있습니다. 표준 세일즈 데이터만을 기술하는 XYZ 회사의 문서 예가 아래와 같습니다:


크게보기

두 가지 문서는 서로 매우 다르지만 동일한 XML 스키마를 공유합니다. 이처럼 하나의 유연한 XML 포맷을 이용하여 다양한 기업의 요구 사항을 반영하는 업계 표준을 구현하는 것이 가능합니다. 또 제너릭 컨테이너 엘리먼트를 위한 재귀적 참조를 활용하여 각 기업이 얼마나 세분화된 정보를 포함시킬 것인지 결정하도록 지원할 수 있습니다. 예를 들어 CompanyABC.xml로부터 현재 재고량에 대한 데이터를 추출하기 위한 XPath가 아래와 같습니다.

'/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/
xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'

이 회사가 보다 세분화된 형태로 데이터를 저장하기를 원하는 경우, 'substore'를 위한 자식 엘리먼트를 아래와 같이 추가할 수 있을 것입니다:

'/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/xn:CompanySpecificContainer/
xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'

이러한 XML 스키마 설계는 각 기업의 요구 사항에 따라 컨텐트를 자유롭게 배치할 수 있는 여지를 제공합니다. 제너릭 컨테이너 엘리먼트와 참조 옵션을 이용하여 각 문서가 별도의 데이터베이스처럼 기능하도록 구성할 수 있습니다. 이러한 파일의 예측 불허적인 성격을 감안할 때, 커스텀 코드 또는 상용 ETL 패키지를 이용하여 이 XML 데이터를 관리하기 위해서는 매우 번거로운 개발 작업이 필요할 것이며 유지보수에도 많은 비용이 필요할 것입니다. 이 XML 스키마를 사용 중인 회사가 새로운 XPath를 포함시키는 경우, 추출 작업을 위한 코드에도 데이터 캡처를 위한 내용이 추가되어야 합니다. 또 업데이트된 XPath가 적용되지 않은 상태에서 파싱된 파일들은 다시 처음부터 파싱 처리 되어야 합니다. 이처럼 복잡한 XML 스키마의 컨텐트를 관리하기 위해서는 여러 가지 까다로운 문제를 고려해야 합니다.

Oracle XML DB 솔루션

Oracle XML DB는 모든 파일을 데이터베이스 내에 저장하므로 위에서 설명한 XPath 매핑 문제로 고민할 필요가 없습니다. Oracle XML DB 환경에서는 문서가 INSERT 처리되는 즉시 문서의 컨텐트를 바로 조회할 수 있습니다. XML 스키마의 유연성 수준에 관계 없이, 문서에 포함된 데이터는 적절한 XPath를 통해 접근될 수 있습니다. 따라서 데이터의 가용성을 극대화하는 한편 유지 보수 비용을 최소화하는 것이 가능합니다.

XML DB 솔루션을 구현하기 위해서는 먼저 XML 스키마를 등록하는 과정이 필요합니다. (정의 파일과 문서는 XML_TEST 디렉토리에 위치합니다):



XML 스키마를 위한 오브젝트-관계형 구조를 생성한 다음에는, (root 엘리먼트의 주석에 명시된) 디폴트 테이블에 XML 파일을 INSERT 처리합니다.

insert into XML_DEFAULT values (XMLTYPE(BFILENAME ('XML_TEST','CompanyABC.xml'),nls_charset_id('AL32UTF8')));
/

파일의 INSERT 작업은 수 분의 일 초 내에 신속하게 완료됩니다. 그리고 바로 관계형 쿼리를 통해 데이터에 접근할 수 있습니다. 현재 인벤토리 현황을 조회하기 위한 쿼리의 예가 아래와 같습니다:


크게보기

이렇게 구현된 환경에서는 XML 스키마 정의를 준수하는 어떤 문서든 관리가 가능합니다. Oracle XML DB의 데이터 중심형 XML 뷰를 이용하여 다양한 컨텐트의 XML 문서를 작성하고 추상화 계층의 구현을 통해 (다른 ETL 툴에서는 불가피하게 수반되는) 개발 과정의 복잡성을 제거할 수 있습니다.

위의 예는 Oracle XML DB의 강력한 XML 저장/인출 기능을 보여 주고 있습니다. 하지만 복잡한 XML 스키마의 경우 변경 작업 또한 매우 빈번하게 발생할 수 있다는 점을 고려할 필요가 있습니다. Oracle XML DB는 변경 사항을 XML 스키마에 어떤 방식으로 적용할까요?

XML 스키마 변경 내역의 관리

앞의 예를 통해 제너릭 컨테이너 엘리먼트와 참조 옵션을 이용하여 스키마의 유연성을 구현하는 방법에 대해 설명하였습니다. 이러한 설계가 XML 스키마의 유연성을 매우 높여 주는 것은 분명합니다. 하지만 각 기업의 요구 사항이 변경될 때마다 CompanySpecific.1.0.xsd 네임스페이스를 수정해야 할 필요성을 함께 고려할 필요가 있습니다.

스키마 정의에 발생하는 변경 사항을 관리하는 것은 XML 기반 솔루션에서 오래 전부터 문제가 되어 왔습니다. XML 스키마가 XML 문서의 검증을 위해 사용된다는 점을 감안하면 이는 당연한 것입니다. 스키마에 정의되지 않은 엘리먼트가 문서에 포함된 경우, 이 문서는 올바르지 않은 포맷을 가진 것으로 간주됩니다. 과거에는 Oracle XML DB에 이에 관련한 약점이 존재했습니다. 등록된 XML 스키마를 변경하기 위해서는 copyEvolve 프로시저를 사용하여 매우 복잡한 작업을 수행해야 했기 때문입니다. copyEvolove 프로시저는 리소스에 락을 걸고, 임시 테이블을 생성하고, 스키마 내의 모든 XML 테이블 데이터를 임시 테이블로 이동하고, 스키마 변경을 적용한 뒤, 다시 데이터를 XML 테이블로 가져옵니다. XML 테이블의 데이터 용량이 증가하면 할 수록 이 작업에 걸리는 시간은 증가합니다. 테이블의 크기에 따라 다를 수 있지만, 하나의 엘리먼트 또는 속성을 스키마에 추가하는 데에도 수 시간이 걸릴 수 있습니다. 복잡한 XML 환경에서는 이러한 해법이 결코 스키마 관리를 위한 대안으로 고려될 수 없습니다.

오라클은 이러한 문제의 해결을 위해 Oracle XML DB 11g에 inPlaceEvolve라는 새로운 프로시저를 추가하였습니다. inPlaceEvolve 프로시저는 데이터 이동 작업 없이 온라인 상태에서 스키마 수정 작업을 수행할 수 있도록 지원합니다. 따라서 복잡한 XML 환경에서 빈번하게 발생하는 변경 작업을 신속하게 완료할 수 있습니다.

앞의 예에서 csProduct 정의에 새로운 엘리먼트를 추가해야 하는 경우를 생각해 봅시다:



Oracle XML DB 11g에서는 이 변경 작업을 매우 쉽고 간단하게 완료할 수 있습니다. 새로운 inPlaceEvolve 프로시저는 스키마 URL과 xdiff XML 스키마를 준수하는 XMLType 문서(XMLDiff)를 필요로 합니다. XMLDiff 문서는 XML 스키마의 변경 사항을 반영한 특수한 포맷의 문서입니다. XMLDiff 문서를 수동으로 생성하는 대신, 오라클 데이터베이스의 xmldiff 함수를 이용하여 자동으로 생성할 수 있습니다.

먼저 업데이트된 XML 스키마 정의 파일인 CompanySpecific.1.1.xsd를 이용하여 새로운 스키마 파일을 생성합니다. 그런 다음 기존 스키마를 첫 번째 매개변수로, 새로운 스키마를 두 번째 매개변수로 사용하여 오라클 데이터베이스 xmldiff 함수를 실행합니다.



XMLDiff 문서를 조회하기 위한 쿼리는 아래와 같습니다.

select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal() from dual;
/

본 예제에서는 XMLDiff 문서의 저장을 위해 CLOB 변수를 사용하고 있습니다.

var diffXMLDoc clob;
begin
select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal() into :diffXMLDoc from dual;
end;
/

XMLDiff 문서를 생성했다면, 이제 PlaceEvolve 프로시저를 호출하여 온라인 상태에서 XML 스키마를 변경할 수 있습니다.



트레이스 파일을 조회해 보면 새로운 엘리먼트가 추가된 것을 확인할 수 있습니다:

change to ct sqltype = csProduct1046_T
------------ QMTS Executing SQL ------------
ALTER TYPE "XMLTEST"."csProduct1046_T" ADD ATTRIBUTE "class" VARCHAR2(4000 CHAR) CASCADE NOT INCLUDING TABLE DATA
/
--------------------------------------------

이 새로운 기능을 이용하여 XML 스키마에 대한 관리 효율성을 크게 개선할 수 있습니다. Oracle XML DB를 대규모 엔터프라이즈 환경에서 사용할 수 있는 가능성 또한 크게 높아졌다고 볼 수 있습니다.

실제 적용

Oracle XML DB 11g는 다른 어떤 대안보다도 유용하고 실질적인 포괄적 컨텐트 관리 솔루션을 제공합니다. Oracle XML DB는 각 문서에 대한 데이터베이스 중심형 뷰를 기반으로, XML 컨텐트의 저장 및 인출을 위한 혁신적이고 강력한 대안을 제공합니다. 다양한 저장 옵션을 이용하여 모든 유형의 문서들을 그 크기나 복잡성에 관계 없이 효과적으로 관리할 수 있습니다. XML 스키마 정의의 온라인 업데이트 기능은 컨텐트가 자주 변경되는 환경에서 Oracle XML DB를 이상적인 솔루션으로 활용될 수 있게 합니다.

본 문서에서 설명된 XML 문서의 처리 방법이 꽤 복잡해 보일 수도 있겠지만, 이러한 방법은 실제로 여러 업계에서 표준으로 활용되기 시작하고 있습니다. 통신 업계의 경우, 무선 업체들이 분산 전송 지표(distributing transmission metrics)를 위해 위에서 설명한 것과 유사한 XML 스키마를 이용하고 있기도 합니다. 복잡한 XML 포맷이 제공하는 가치와 유연성, 그리고 Oracle XML DB의 강력한 컨텐트 관리 기능을 감안할 때, Oracle XML DB 11g의 미래는 매우 밝다고 볼 수 있습니다.

---

V.J. Jain 은 Varun Jain Inc의 오라클 애플리케이션 및 오라클 데이터베이스 부문 수석 컨설턴트입니다. 그가 기고한 다른 자료들을 Oracle-Developer.com에서 확인할 수 있습니다.

여러분의 의견을 보내 주십시오

제공 : DB포탈사이트 DBguide.net

 

출처명 : 한국오라클