다음을 통해 공유

XML 사용을 위한 최선의 구현 방법

  • 아티클

SQL Server 2005는 XML 데이터 처리를 위한 포괄적인 지원을 제공합니다. XML 값은 XML 스키마의 컬렉션에 따라 형식화되거나 형식화되지 않은 상태로 유지될 수 있는 xml 데이터 형식의 열에 기본적으로 저장될 수 있습니다. XML 열을 인덱싱할 수 있으며 XQuery 및 XML DML을 사용하여 데이터를 세밀하게 조작할 수 있습니다. XML DML은 데이터 수정을 위한 확장 언어입니다.

SQL Server 2000 및 SQLXML 웹 버전은 강력한 XML 데이터 관리 기능을 제공합니다. 이러한 기능은 관계형 데이터와 XML 데이터 간의 매핑에 집중되어 있습니다. 관계형 데이터에 대한 XML 뷰는 XML 데이터에 대한 데이터 대량 로드, 쿼리 및 업데이트 기능을 지원하는 XML 중심 접근 방식을 제공하는 AXSD(주석 지정 XSD)를 사용하여 정의됩니다. Transact-SQL 확장 언어는 FOR XML을 사용하여 관계형 쿼리 결과를 XML로 매핑하고 OPENXML을 사용하여 XML로부터 관계형 뷰를 생성하기 위한 SQL 중심 접근 방식을 제공합니다. 이러한 지원은 SQL Server 2005에서 더욱 확장되었습니다. 새로 추가된 네이티브 XML 지원과 함께 SQL Server 2005는 반구조화된 데이터 및 구조화되지 않은 데이터 관리를 위한 다양한 응용 프로그램을 개발할 수 있는 강력한 플랫폼을 제공합니다.

이 항목에서는 XML 데이터 모델링을 위한 지침과 SQL Server 2005에서의 활용 방식에 대해 설명합니다. 이 항목은 다음 두 섹션으로 구분됩니다.

  • 데이터 모델링
    XML 데이터는 네이티브 xml 데이터 형식 및 테이블로 조각화된 XML을 사용하여 SQL Server 2005에서 여러 방식으로 저장될 수 있습니다. 이 항목에서는 XML 데이터 모델링에 적합한 방식을 선택하기 위한 지침을 제공합니다. 또한 XML 데이터 인덱싱, 속성 승격 및 XML 인스턴스 형식화에 대해서도 설명됩니다.
  • 활용 방식
    이 섹션에서는 XML 데이터의 서버 로드와 쿼리 컴파일 시의 유형 추론과 같은 활용 방식과 관련된 항목에 대해 설명합니다. 이 섹션에서는 또한 밀접하게 관련된 기능을 설명 및 비교하고 이러한 기능에 대한 적합한 활용 방식을 제안합니다. 이러한 내용은 예와 함께 설명됩니다.

데이터 모델링

이 섹션에서는 SQL Server 2005에서 XML을 사용해야 하는 이유에 대해 간단히 설명합니다. 이 섹션에서는 또한 네이티브 XML 저장소 및 XML 뷰 기술 선택을 위한 지침을 제공하고 데이터 모델링 방식을 제안합니다.

관계형 데이터 모델 또는 XML 데이터 모델

데이터가 알려진 스키마로 복잡하게 구조화된 경우 관계형 모델이 데이터 저장소에 가장 적합할 수 있습니다. SQL Server는 사용자에게 필요한 기능 및 도구를 제공합니다. 반면에 반구조화되어 있거나 구조화되지 않았거나 데이터 또는 구조화 상태를 알 수 없는 경우에는 이러한 데이터의 모델링에 대한 주의가 필요합니다.

구조적 및 의미적 태그를 사용하여 데이터의 이동성을 보장하기 위해 플랫폼 독립적인 모델이 필요한 경우에는 XML이 좋은 대안입니다. 또한 XML은 다음과 같은 상황에서도 적절한 대안이 될 수 있습니다.

  • 데이터가 산발적이거나 데이터 구조를 알 수 없거나 데이터 구조가 이후에 크게 변경될 수 있습니다.
  • 데이터가 엔터티 간 참조 대신 포함 계층을 나타내며 재귀적일 수 있습니다.
  • 데이터에 정렬이 내재되어 있습니다.
  • 데이터 구조를 기반으로 데이터를 쿼리하거나 데이터 일부를 업데이트하고자 합니다.

이러한 상황에 하나도 해당되지 않으면 관계형 데이터 모델을 사용해야 합니다. 예를 들어 데이터가 XML 형식으로 되어 있지만 응용 프로그램에서 데이터의 저장 및 검색을 위해서만 데이터베이스를 사용하는 경우에는 [n]varchar(max) 열만 있으면 됩니다. XML 열에 데이터를 저장하면 추가 이점이 있습니다. 이러한 이점에 대한 예로, 엔진에서 데이터가 잘 작성되었거나 유효한지 여부를 확인할 수 있으며, XML 데이터의 세부적 쿼리 및 업데이트가 지원됩니다.

SQL Server 2005에서 XML 데이터를 저장하는 이유

다음은 파일 시스템에서 XML 데이터를 관리하는 대신 SQL Server 2005에서 네이티브 XML 기능을 사용하는 몇 가지 이유입니다.

  • 효율적이고 실용적인 방식으로 XML 데이터를 공유, 쿼리 및 수정하고자 합니다. 세부적 데이터 액세스는 응용 프로그램에 중요한 요소입니다. 예를 들어 XML 문서 내에서 일부 섹션을 추출하거나 전체 문서를 바꾸지 않고 새 섹션을 삽입합니다.
  • 관계형 데이터 및 XML 데이터가 있고 응용 프로그램 내에서 관계형 데이터 및 XML 데이터 사이의 호환성이 필요합니다.
  • 도메인 간 응용 프로그램에서 쿼리 및 데이터 수정을 위한 언어 지원이 필요합니다.
  • 서버의 데이터가 잘 작성되도록 보장하고 선택적으로 XML 스키마에 따라 데이터의 유효성을 검사고자 합니다.
  • 효율적인 쿼리 처리 및 확장성을 위해 XML 데이터를 인덱싱하고 최상의 쿼리 최적화 프로그램을 사용고자 합니다.
  • XML 데이터에 대한 SOAP, ADO.NET 및 OLE DB 액세스가 필요합니다.
  • XML 데이터 관리를 위해 데이터베이스 서버의 관리 기능을 사용고자 합니다. 예를 들어 이러한 기능에는 백업, 복구 및 복제가 포함될 수 있습니다.

이러한 상황에 하나도 해당되지 않으면 [n]varchar(max) 또는 **varbinary(max)**와 같은 비-XML의 큰 개체 유형으로 데이터를 저장하는 것이 좋습니다.

XML 저장소 옵션

SQL Server 2005의 XML 저장소 옵션에는 다음이 포함됩니다.

  • xml 데이터 형식의 네이티브 저장소
    데이터의 XML 내용을 보존하는 내부 표현으로 데이터가 저장됩니다. 여기에는 포함 계층, 문서 순서, 요소 및 특성 값이 포함됩니다. 특히 XML 데이터의 InfoSet 내용이 보존됩니다. InfoSet에 대한 자세한 내용은 http://www.w3.org/TR/xml-infoset을 방문하십시오. InfoSet 내용은 다음 정보가 포함되지 않기 때문에 테스트 XML의 동일 복사본이 될 수 없습니다. 제외되는 정보는 중요하지 않은 공백, 특성 순서, 네임스페이스 접두사 및 XML 선언입니다.
    XML 스키마에 바인딩된 xml 데이터 형식인 형식화된 xml 데이터 형식에 대해 PSVI(Post-Schema Validation InfoSet)는 InfoSet에 유형 정보를 추가하고 내부 표현으로 인코딩됩니다. 이렇게 하면 구문 분석 속도가 크게 향상됩니다. 자세한 내용은 http://www.w3.org/TR/xmlschema-1 및 http://www.w3.org/TR/xmlschema-2에서 W3C XML 스키마 사양을 참조하십시오.
  • XML 및 관계형 저장소 간 매핑
    XML은 AXSD(주석 지정 스키마)를 사용하여 하나 이상의 테이블에 있는 열로 분해됩니다. 이렇게 하면 관계형 수준에서 데이터의 정확성이 보존됩니다. 그 결과 요소 간 순서가 무시되더라도 계층적 구조가 보존됩니다. 스키마는 재귀적일 수 없습니다.
  • 큰 개체 저장소 [n]varchar(max) 및 varbinary(max)
    데이터의 동일 복사본이 저장됩니다. 이 옵션은 법률 문서와 같은 특수한 용도의 응용 프로그램에 유용합니다. 대부분의 응용 프로그램에는 정확한 복사본이 필요하지 않으며 XML 내용만으로도 충분합니다(InfoSet 정확성).

일반적으로 이러한 접근 방식을 조합해서 사용해야 할 수 있습니다. 예를 들어 xml 데이터 형식의 열에 XML 데이터를 저장하고 XML 열에서 관계형 열로 속성을 승격해야 할 수 있습니다. 또는 비-XML 열에 비재귀적인 부분을 저장하고 재귀적인 부분만 xml 데이터 형식의 열에 저장하는 매핑 기술을 사용할 수 있습니다.

XML 기술 선택

네이티브 XML과 XML 뷰 간의 XML 기술 선택은 일반적으로 다음 요소에 따라 달라집니다.

  • 저장소 옵션
    XML 데이터는 큰 개체 저장소에 적합하거나(예: 제품 설명서) 관계형 열에 있는 저장소에 더 적합할 수 있습니다(예: XML로 변환된 라인 항목). 각 저장소 옵션은 서로 다른 수준의 문서 정확성을 보존합니다.
  • 쿼리 기능
    쿼리의 특성과 XML 데이터를 쿼리하는 정도에 따라 적합한 저장소 옵션을 찾을 수 있습니다. XML 노드에 대한 조건자 평가와 같은 세부적인 XML 데이터 쿼리는 두 개의 저장소 옵션에서 서로 다르게 지원됩니다.
  • XML 데이터 인덱싱
    XML 쿼리 성능의 속도를 높이기 위해 XML 데이터를 인덱싱할 수 있습니다. 인덱싱 옵션은 스토리지 옵션별로 다르므로 작업을 최적화할 수 있는 적합한 옵션을 선택해야 합니다.
  • 데이터 수정 기능
    일부 작업에는 XML 데이터에 대한 세부적인 수정 작업이 포함됩니다. 예를 들어 특정 작업에는 문서 내의 새 섹션을 추가 작업이 포함되지만 웹 콘텐츠와 같은 다른 작업에는 이러한 작업이 포함되지 않습니다. 데이터 수정 언어 지원은 응용 프로그램에 있어서 중요한 요소입니다.
  • 스키마 지원
    XML 데이터를 스키마에 의해 기술할 수 있으며 이러한 스키마는 XML 스키마 문서일 수도 혹은 아닐 수도 있습니다. 스키마 바인딩 XML 지원은 XML 기술에 따라 달라집니다.

선택한 옵션에 따라 성능 특성이 달라집니다.

네이티브 XML 저장소

서버에서 xml 데이터 형식의 열에 XML 데이터를 저장할 수 있습니다. 이 옵션은 다음과 같은 상황에서 적절한 대안이 될 수 있습니다.

  • 서버에 XML 데이터를 저장하고 동시에 문서 순서 및 문서 구조를 보존할 수 있는 직관적인 방식이 필요합니다.
  • XML 데이터에 대한 스키마가 있거나 없습니다.
  • XML 데이터를 쿼리하고 수정해야 합니다.
  • 신속한 쿼리 처리를 위해 XML 데이터를 인덱싱해야 합니다.
  • XML 데이터 및 XML 스키마를 관리하려면 응용 프로그램에 시스템 카탈로그 뷰가 필요합니다.

네이티브 XML 저장소는 구조 범위가 포함된 XML 문서가 있거나 관계형 구조로 매핑하기 어려운 여러 스키마 또는 복잡한 스키마에 해당하는 XML 문서가 있는 경우에 유용합니다.

예: xml 데이터 형식을 사용하여 XML 데이터 모델링

각 항목에 대한 별도의 장으로 구성되어 있고 각 장 내에 여러 섹션이 포함된 XML 형식의 제품 설명서를 가정해 보십시오. 하나의 섹션에는 하위 섹션이 포함될 수 있습니다. 따라서 <section>은 재귀적 요소입니다. 제품 설명서에는 다량의 콘텐츠, 다이어그램 및 기술 자료가 혼합되어 있으며 데이터는 반구조적입니다. 사용자는 "인덱싱" 장에서 "클러스터형 인덱스" 섹션을 검색하는 것과 같이 원하는 항목을 문맥에 따라 검색하고 많은 기술 자료를 쿼리할 수 있습니다.

XML 문서에 적합한 저장소 모델은 xml 데이터 형식의 열입니다. 이 모델은 XML 데이터에 대한 InfoSet 내용을 보존합니다. XML 열을 인덱싱하면 쿼리 성능이 높아집니다.

예: XML 데이터에 대한 정확한 복사본 유지

이해를 돕기 위해 정부 규제에 따라 XML 문서에 대한 정확한 텍스트 복사본을 유지해야 한다고 가정해 보십시오. 예를 들어 여기에는 서명된 문서, 법률 문서 또는 상품 거래 주문 내역 등이 포함될 수 있습니다. 문서를 [n]varchar(max) 열에 저장할 수 있습니다.

쿼리를 위해서는 데이터를 런타임에 xml 데이터 형식으로 변환하고 여기에서 Xquery를 실행합니다. 런타임 변환은 특히 문서가 큰 경우 비용이 많이 듭니다. 쿼리를 자주 수행하는 경우 xml 데이터 형식의 열에 문서를 중복해서 저장하고 [n]varchar(max) 열에서 정확한 문서 복사본을 반환하는 동안 이를 인덱싱할 수 있습니다.

XML 열은 [n]varchar(max) 열을 기반으로 계산을 수행하는 계산 열일 수 있습니다. 그러나 XML 계산 열에서는 XML 인덱스를 만들 수 없으며 [n]varchar(max) 또는 varbinary(max) 열을 기반으로 XML 인덱스를 작성할 수도 없습니다.

XML 뷰 기술

데이터베이스에 있는 테이블과 XML 스키마 간의 매핑을 정의하면 영구적 데이터에 대한 "XML 뷰"를 만들 수 있습니다. XML 대량 로드를 사용하면 XML 뷰를 사용하여 기본 테이블을 채울 수 있습니다. XML 뷰는 XPath 버전 1.0을 사용하여 쿼리할 수 있으며, 이 쿼리는 테이블에서 SQL 쿼리로 변환됩니다. 이와 마찬가지로 이들 테이블에 업데이트를 전파할 수도 있습니다.

이 기술은 다음과 같은 경우 유용합니다.

  • 기존 관계형 데이터에 대해 XML 뷰를 사용하는 XML 중심 프로그래밍 모델을 갖고자 합니다.
  • 외부 파트너가 제공한 XML 데이터에 대한 스키마(XSD, XDR)가 있습니다.
  • 데이터에서 순서가 중요하지 않거나, 쿼리 테이블 데이터가 재귀적이지 않거나, 최대 재귀 깊이가 미리 알려져 있습니다.
  • XPath 버전 1.0을 사용하여 XML 뷰를 통해 데이터를 쿼리 및 수정해야 합니다.
  • XML 데이터를 대량 로드하고 XML 뷰를 사용하여 기본 테이블로 분해해야 합니다.

이러한 예로는 데이터 교환 및 웹 서비스에 대해 XML로 제공된 관계형 데이터와 고정 스키마가 포함된 XML 데이터가 있습니다. 자세한 내용은 MSDN Online Library를 참조하십시오.

예: AXSD(주석 지정 XML 스키마)를 사용하여 데이터 모델링

이해를 돕기 위해 고객, 주문 및 라인 항목 등과 같은 기존 관계형 데이터가 있고 이를 XML로 처리하려는 경우를 가정해 보십시오. 관계형 데이터에 대해 AXSD를 사용하여 XML 뷰를 정의합니다. XML 뷰를 사용하면 XML 데이터를 테이블에 대량 로드하고 XML 뷰를 사용하여 관계형 데이터를 쿼리 및 업데이트할 수 있습니다. 이 모델은 XML 태그가 포함된 데이터를 다른 응용 프로그램과 교환하고 SQL 응용 프로그램을 방해 받지 않고 실행해야 하는 경우에 유용합니다.

하이브리드 모델

관계형 및 xml 데이터 형식의 열을 조합하면 데이터 모델링에 적합한 경우가 많습니다. XML 데이터의 일부 값은 관계형 열에 저장하고 나머지 값이나 전체 XML 값은 XML 열에 저장할 수 있습니다. 이렇게 하면 관계형 열에서 만든 인덱스와 잠금 특성을 더욱 자세히 제어할 수 있다는 점에서 성능이 향상됩니다.

관계형 열에 저장하는 값은 작업에 따라 달라집니다. 예를 들어 경로 식 /Customer/@CustId에 따라 모든 XML 값을 검색하는 경우 CustId 특성의 값을 관계형 열로 승격하고 이를 인덱싱하면 쿼리 속도가 빨라집니다. 반면에 XML 데이터가 관계형 열로 포괄적으로 중복되지 않게 분해된 경우 리어셈블리 비용이 상당히 높을 수 있습니다.

예를 들어 구조화 수준이 높은 XML 데이터의 경우 테이블의 내용이 XML로 변환되어 모든 값을 관계형 열로 매핑하고 XML 뷰 기술을 사용할 수 있습니다.

xml 데이터 형식을 사용하여 데이터 모델링

이 섹션에서는 네이티브 XML 저장소에 대한 데이터 모델링 항목에 대해 설명합니다. 여기에는 XML 데이터 인덱싱, 속성 승격 및 형식화된 xml 데이터 형식이 포함됩니다.

같은 테이블 또는 다른 테이블

xml 데이터 형식의 열을 다른 관계형 열이 포함된 테이블이나 기본 테이블에 대한 외래 키 관계에 있는 별개의 테이블에 만들 수 있습니다.

다음 조건 중 하나에 해당하면 같은 테이블에 xml 데이터 형식의 열을 만듭니다.

  • 응용 프로그램이 XML 열에서 데이터 검색을 수행하고 XML 열에 XML 인덱스가 필요하지 않습니다.
  • xml 데이터 형식의 열에 XML 인덱스를 작성하려고 하며 기본 테이블의 기본 키는 해당 클러스터링 키와 같습니다. 자세한 내용은 xml 데이터 형식 열 인덱싱을 참조하십시오.

다음 조건에 맞는 경우 별개의 테이블에 xml 데이터 형식의 열을 만듭니다.

  • xml 데이터 형식의 열에 XML 인덱스를 작성하려고 하지만 기본 테이블의 기본 키가 해당 클러스터링 키와 다르거나, 기본 테이블에 기본 키가 없거나, 기본 테이블이 힙(비 클러스터링 키)입니다. 기본 테이블이 이미 있는 경우에는 이 조건에 부합될 수 있습니다.
  • 테이블에 있는 XML 열로 인해 테이블 검색 속도가 느려지는 것을 원치 않습니다. XML 열은 행 안에 있든 행 밖에 있든 간에 공간을 사용합니다.

XML 데이터의 세분성

XML 열에 저장된 XML 데이터의 세분성은 잠금에 있어서 매우 중요하며, 업데이트에 대해서도 역시 중요합니다. SQL Server는 XML 및 비-XML 데이터에 대해서 모두 같은 잠금 메커니즘을 사용합니다. 따라서 행 수준의 잠금으로 인해 행에 있는 모든 XML 인스턴스가 잠깁니다. 세분성이 큰 경우 업데이트를 위해 큰 XML 인스턴스를 잠그면 다중 사용자 환경에서 처리량이 줄어 듭니다. 반면에 심각한 분해 작업을 수행하면 개체 캡슐화가 손실되며 리어셈블리 비용이 증가합니다.

데이터 모델링 요구 사항과 잠금 및 업데이트 특성 간의 균형은 훌륭한 디자인을 위해 중요한 요소입니다. 하지만 SQL Server 2005에서 실제 저장된 XML 인스턴스의 크기는 그렇게 중요하지 않습니다.

예를 들어 XML 인스턴스에 대한 업데이트는 저장된 기존 XML 인스턴스가 해당 업데이트된 버전과 비교되는 부분적 BLOB(Binary Large Object) 업데이트와 부분적 인덱스 업데이트에 대한 새로운 지원을 사용하여 수행됩니다. 부분적 BLOB(Binary Large Object) 업데이트는 두 개의 XML 인스턴스 간의 차등 비교를 수행하고 다른 점만 업데이트합니다. 부분적 인덱스 업데이트는 XML 인덱스에서 변경되어야 하는 행만 수정합니다.

형식화되지 않은, 형식화된 및 제한된 xml 데이터 형식

SQL Server 2005에서 xml 데이터 형식은 ISO SQL-2003 표준의 xml 데이터 형식을 구현합니다. 따라서 잘 작성된 XML 버전 1.0 문서를 저장할 수 있으며 텍스트 노드 및 형식화되지 않은 XML 열의 추상적 개수의 최상위 요소가 포함된 XML 내용 조각을 저장할 수 있습니다. 시스템은 데이터가 잘 작성되었는지 확인하고, 열이 XML 스키마로 바인딩되도록 요구하지 않으며, 넓은 의미에서 잘 작성되지 않은 데이터는 거부합니다. 이러한 조건은 형식화되지 않은 XML 변수 및 매개 변수의 경우에도 부합됩니다.

XML 데이터를 기술하는 XML 스키마가 있는 경우 이 스키마를 XML 열과 연결하여 형식화된 XML을 생성할 수 있습니다. XML 스키마는 데이터 유효성을 검사하고, 쿼리 및 데이터 수정 문 컴파일 시에 형식화되지 않은 XML보다 정확한 형식 검사를 수행하며, 저장소 및 쿼리 처리를 최적화합니다.

다음 경우에 형식화되지 않은 xml 데이터 형식을 사용합니다.

  • XML 데이터에 대한 스키마가 없습니다.
  • 스키마가 있지만 서버에서 데이터 유효성 검사를 수행하지 않습니다. 이러한 경우는 데이터를 서버에 저장하기 전에 응용 프로그램이 클라이언트측 유효성 검사를 수행하거나, 스키마에 대해 유효하지 않은 XML 데이터를 임시적으로 저장하거나, 서버에서 지원되지 않는 스키마 구성 요소(예: key/keyref)를 사용하는 경우입니다.

다음 경우에 형식화된 xml 데이터 형식을 사용합니다.

  • XML 데이터에 대한 스키마가 있으며 이 XML 스키마에 따라 서버에서 XML 데이터의 유효성을 검사하고자 합니다.
  • 형식 정보에 따라 저장소 및 쿼리 최적화를 활용합니다.
  • 쿼리 컴파일 시 형식 정보를 더욱 활용합니다.

형식화된 XML 열, 매개 변수 및 변수는 XML 문서 또는 내용을 저장할 수 있습니다. 하지만 선언 시에 저장하는 항목이 문서 또는 내용인지 여부를 플래그로 지정해야 합니다. 또한 XML 스키마의 컬렉션을 제공해야 합니다. 각 XML 인스턴스에 정확히 하나의 최상위 요소가 있는 경우 DOCUMENT를 지정합니다. 그렇지 않으면 CONTENT를 사용합니다. 쿼리 컴파일러는 쿼리 컴파일 중에 형식 검사에서 DOCUMENT 플래그를 사용하여 단일 항목인 최상위 요소를 유추합니다.

XML 열을 형식화하는 것 외에도 형식화된 또는 형식화되지 않은 xml 데이터 형식의 열에서 관계형(열 또는 행) 제약 조건을 사용할 수 있습니다. 다음 경우에 제약 조건을 사용합니다.

  • 비즈니스 규칙을 XML 스키마에 표현할 수 없습니다. 예를 들어 꽃 판매점의 배달 주소는 해당 영업소 위치에서 50마일 이내에 있어야 합니다. 이러한 사항은 XML 열에 대한 제약 조건으로 작성될 수 있습니다. 제약 조건에는 xml 데이터 형식의 메서드가 포함될 수 있습니다.
  • 제약 조건에 테이블의 XML 또는 비-XML 열이 포함됩니다. 한 예는 관계형 CustomerID 열에 있는 값과 일치하는 XML 인스턴스에 있는 고객의 ID(/Customer/@CustId)에 대한 강제 적용입니다.

문서 유형 정의(DTD)

xml 데이터 형식의 열, 변수 및 매개 변수는 DTD가 아닌 XML 스키마를 사용하여 형식화될 수 있습니다. 하지만 인라인 DTD는 형식화되지 않은 XML 및 형식화된 XML 모두에 대해 사용하여 기본값을 제공하고 엔터티 참조를 해당 확장 형식으로 바꿀 수 있습니다.

타사 도구를 사용하여 DTD를 XML 스키마 문서로 변환하고 XML 스키마를 데이터베이스에 로드할 수 있습니다.

xml 데이터 형식 열 인덱싱

XML 인덱스를 xml 데이터 형식의 열에 만들 수 있습니다. 그러면 열에 있는 XML 인스턴스에 대해 모든 태그, 값 및 경로가 인덱싱되어 쿼리 성능이 향상됩니다. 다음 경우에 응용 프로그램에서 XML 인덱스를 활용할 수 있습니다.

  • XML 열의 쿼리가 작업에서 일반적입니다. 데이터 수정 중의 XML 인덱스 유지 관리 비용이 고려되어야 합니다.
  • XML 값이 비교적 크며 검색된 부분은 비교적 작습니다. 인덱스를 작성하면 런타임 시 전체 데이터의 구문 분석을 방지하므로 인덱스 조회를 통해 쿼리 처리를 효율화할 수 있습니다.

XML 열의 첫 번째 인덱스는 기본 XML 인덱스입니다. 다음 섹션의 설명과 같이 기본 인덱스를 사용할 때 3가지 유형의 보조 XML 인덱스를 XML 열에 만들어서 일반적인 쿼리 클래스 속도를 높일 수 있습니다.

기본 XML 인덱스

이 인덱스는 XML 열의 XML 인스턴스 내에 있는 모든 태그, 값 및 경로를 인덱싱합니다. XML 열이 있는 테이블인 기본 테이블에는 해당 테이블의 기본 키에 클러스터형 인덱스가 있어야 합니다. 기본 키는 인덱스 행과 기본 테이블에 있는 행의 상관 관계를 지정하는 데 사용됩니다. 전체 XML 인스턴스는 XML 열로부터 검색됩니다(예: SELECT *). 쿼리에서는 기본 XML 인덱스를 사용하고 인덱스 자체를 사용하여 스칼라 값이나 XML 하위 트리를 반환합니다.

예: 기본 XML 인덱스 만들기

대부분의 예에서는 형식화되지 않은 XML 열이 포함된 테이블 T(pk INT PRIMARY KEY, xCol XML)가 사용됩니다. 이러한 예는 직관적인 방식에 따라 형식화된 XML로 확장될 수 있습니다. 형식화된 XML의 사용 방법은 xml 데이터 형식을 참조하십시오. 간단한 설명을 위해 쿼리는 다음에 표시된 것과 같이 XML 데이터 인스턴스에 대해 기술됩니다.

<book genre="security" publicationdate="2002" ISBN="0-7356-1588-2">
   <title>Writing Secure Code</title>
   <author>
      <first-name>Michael</first-name>
      <last-name>Howard</last-name>
   </author>
   <author>
      <first-name>David</first-name>
      <last-name>LeBlanc</last-name>
   </author>
   <price>39.99</price>
</book>

다음 문은 테이블 T의 XML 열 xCol에서 idx_xCol이라는 XML 인덱스를 만듭니다.

CREATE PRIMARY XML INDEX idx_xCol on T (xCol)

보조 XML 인덱스

기본 XML 인덱스를 만든 다음에는 보조 XML 인덱스를 만들어서 작업 내 여러 쿼리 클래스의 속도를 높일 수 있습니다. 3가지 보조 XML 인덱스인 PATH, PROPERTY 및 VALUE는 각각 경로 기반 쿼리, 사용자 지정 속성 관리 시나리오 및 값 기반 쿼리에 유용합니다. PATH 인덱스는 열의 모든 XML 인스턴스에 대해 문서 순서에 있는 각 XML 노드 대한 (경로, 값) 쌍에 B+ 트리를 작성합니다. PROPERTY 인덱스는 각 XML 인스턴스 내의 (PK, 경로, 식) 쌍에 B+-트리를 작성합니다(여기서 PK는 기본 테이블의 기본 키). 마지막으로 VALUE 인덱스는 XML 열의 모든 XML 인스턴스에서 문서 순서에 있는 각 노드에 대한 (값, 경로) 쌍에 B+-트리를 만듭니다.

다음은 이러한 인덱스를 하나 이상 만들기 위한 일부 지침입니다.

  • 작업에서 XML 열에 경로 식이 중요하게 사용되는 경우 PATH 보조 XML 인덱스는 작업 속도를 높일 수 있습니다. 가장 일반적인 경우는 Transact-SQL의 WHERE 절에서 XML 열에 대해 exist() 메서드를 사용하는 것입니다.
  • 작업에 경로 식을 사용하여 개별적인 XML 인스턴스로부터 여러 값을 검색하는 경우 PROPERTY 인덱스에 있는 각 XML 인스턴스 내의 경로를 클러스터링하면 도움이 될 수 있습니다. 이러한 시나리오는 개체의 속성이 인출되고 해당 기본 키 값이 알려진 속성 모음 시나리오에서 일반적으로 발생합니다.
  • 작업에 해당 값이 포함된 요소 또는 특성 이름을 알지 못하는 상태에서 XML 인스턴스 내의 값을 쿼리하는 작업이 포함되는 경우 VALUE 인덱스를 만들 수 있습니다. 이러한 경우는 //author[last-name="Howard"](<author> 요소는 계층의 임의 수준에서 발생 가능)와 같은 하위 항목 축 조회 시에 일반적으로 발생합니다. 또한 /book [@* = "novel"](쿼리가 "novel" 값이 있는 일부 특성을 포함하는 <book> 요소 조회)과 같은 와일드카드 쿼리에서 발생합니다.
예: 경로 기반 조회

이해를 돕기 위해 다음 쿼리가 작업에서 일반적인 것으로 가정해 보십시오.

SELECT pk, xCol
FROM   T
WHERE  xCol.exist ('/book/@genre[.="novel"]') = 1

경로 식 /book/@genre와 값 "novel"은 PATH 인덱스의 키 필드에 해당합니다. 따라서 PATH 유형의 보조 XML 인덱스는 이 작업에 유용합니다.

CREATE XML INDEX idx_xCol_Path on T (xCol)
   USING XML INDEX idx_xCol FOR PATH
예: 개체의 속성 인출

테이블 T의 각 행에서 책의 분야, 제목 및 ISBN과 같은 속성을 검색하는 다음 쿼리를 가정해 보십시오.

SELECT xCol.value ('(/book/@genre)[1]', 'varchar(50)'),
    xCol.value ('(/book/title/text())[1]', 'varchar(50)'),
    xCol.value ('(/book/@ISBN)[1]', 'varchar(50)')
FROM    T

속성 인덱스는 이 경우에 유용하며 다음과 같이 생성됩니다.

CREATE XML INDEX idx_xCol_Property on T (xCol)
   USING XML INDEX idx_xCol FOR PROPERTY
예: 값 기반 쿼리

다음 쿼리에서 하위 항목 또는 자체 축(//)은 ISBN 값에 따른 조회에 VALUE 인덱스 사용이 유용하도록 부분 경로를 지정합니다.

SELECT xCol
FROM    T
WHERE    xCol.exist ('//book/@ISBN[. = "0-7356-1588-2"]') = 1

VALUE 인덱스는 다음과 같이 생성됩니다.

CREATE XML INDEX idx_xCol_Value on T (xCol)
   USING XML INDEX idx_xCol FOR VALUE

XML 열의 전체 텍스트 인덱스

XML 값의 내용을 인덱싱하지만 XML 태그는 무시하는 전체 텍스트 인덱스를 XML 열에 만들 수 있습니다. 특성 값은 태그의 일부로 간주되고 요소 태그는 토큰 경계로 사용되기 때문에 전체 텍스트 인덱싱되지 않습니다. 가능한 경우 다음과 같은 방식으로 전체 텍스트 검색을 XML 인덱스와 조합할 수 있습니다.

  • 먼저 SQL 전체 텍스트 검색을 사용하여 원하는 XML 값을 필터링합니다.
  • 그런 다음 XML 열에서 XML 인덱스를 사용하는 해당 XML 값을 쿼리합니다.
예: 전체 텍스트 검색과 XML 쿼리 조합

XML 열에 전체 텍스트 인덱스를 만든 후 다음 쿼리는 XML 값에 책 제목 중 "custom"이라는 단어가 포함되어 있는지 확인합니다.

SELECT * 
FROM   T 
WHERE  CONTAINS(xCol,'custom') 
AND    xCol.exist('/book/title/text()[contains(.,"custom")]') =1

contains() 메서드는 전체 텍스트 인덱스를 사용하여 문서의 아무 곳에나 "custom"이 포함된 XML 값을 분류합니다. exist() 절은 "custom"이 책의 제목 부분에 있는지 확인합니다.

contains() 및 XQuery **contains()**를 사용하는 전체 텍스트 검색은 서로 다른 의미를 가집니다. 후자는 하위 문자열 일치 검색이며 전자는 형태소 분석을 사용하는 토큰 일치 검색입니다. 따라서 검색이 제목에 "run"이 포함된 문자열을 찾는 경우, 전체 텍스트 contains() 및 Xquery **contains()**가 모두 만족하기 때문에 일치 항목에는 "run", "runs" 및 "running"이 포함됩니다. 하지만 쿼리가 제목에 있는 "customizable"이라는 단어는 검색하지 못하는데 그 이유는 Xquery **contains()**는 만족하지만 전체 텍스트 **contains()**는 실패하기 때문입니다. 일반적으로 순수한 부분 문자열 비교를 위해 전체 텍스트 contains() 절을 제거해야 합니다.

또한 전체 텍스트 검색은 단어의 형태소 분석을 사용하지만 XQuery **contains()**는 리터럴 일치 검색입니다. 이러한 차이점은 다음 예에서 확인할 수 있습니다.

예: 형태소 분석을 사용하여 XML 값에서 전체 텍스트 검색

이전 예에서 수행된 XQuery contains() 검사는 일반적으로 제거할 수 없습니다. 다음 쿼리를 살펴보십시오.

SELECT * 
FROM   T 
WHERE  CONTAINS(xCol,'run')

문서에 있는 "ran"이라는 단어는 형태소 분석으로 인해 검색 조건과 일치합니다. 또한 검색 컨텍스트는 XQuery를 사용하여 검사되지 않습니다.

전체 텍스트 인덱싱되는 AXSD를 사용하여 XML을 관계형 열로 분해하는 경우 XML 뷰에 대해 발생하는 XPath 쿼리는 기본 테이블에서 전체 텍스트 검색을 수행하지 않습니다.

속성 승격

쿼리가 주로 적은 수의 요소 및 특성 값으로 만들어진 경우 이러한 수량을 관계형 열로 승격시킬 수 있습니다. 이 방식은 전체 XML 인스턴스를 검색하는 동안 XML 데이터의 일부에 대해서 쿼리가 실행된 경우에 유용합니다. XML 열에 XML 인덱스를 만들 필요는 없습니다. 대신 승격된 열을 인덱싱할 수 있습니다. 승격된 열을 사용하려면 쿼리를 다시 작성해야 합니다. 즉, 쿼리 최적화 프로그램은 XML 열에 있는 쿼리를 승격된 열로 다시 대상화하지 않습니다.

승격된 열은 같은 테이블에 있는 계산 열이거나 테이블에서 사용자가 유지 관리하는 별개의 열일 수 있습니다. 각 XML 인스턴스로부터 단일 항목 값이 승격되는 경우에는 이것으로 충분합니다. 하지만 다중 값 속성의 경우 다음 섹션의 설명과 같이 속성에 대해 별개의 테이블을 만들어야 합니다.

xml 데이터 형식에 따른 계산 열

계산 열은 xml 데이터 형식 메서드를 호출하는 사용자 정의 함수를 사용하여 만들 수 있습니다. 계산 열의 유형은 XML을 포함하는 모든 SQL 유형일 수 있습니다. 다음 예에서 확인할 수 있습니다.

예: xml 데이터 형식 메서드에 따른 계산 열

책 ISBN 번호에 대한 사용자 정의 함수를 만듭니다.

CREATE FUNCTION udf_get_book_ISBN (@xData xml)
RETURNS varchar(20)
BEGIN
   DECLARE @ISBN   varchar(20)
   SELECT @ISBN = @xData.value('/book[1]/@ISBN', 'varchar(20)')
   RETURN @ISBN 
END

ISBN에 대한 테이블에 계산 열을 추가합니다.

ALTER TABLE      T
ADD   ISBN AS dbo.udf_get_book_ISBN(xCol)

계산 열은 일반적인 방식으로 인덱싱될 수 있습니다.

예: xml 데이터 형식 메서드에 따른 계산 열 쿼리

ISBN이 0-7356-1588-2인 <book>을 가져오려면

SELECT xCol
FROM   T
WHERE  xCol.exist('/book/@ISBN[. = "0-7356-1588-2"]') = 1

다음과 같이 계산 열을 사용하도록 XML 열의 쿼리를 다시 작성할 수 있습니다.

SELECT xCol
FROM   T
WHERE  ISBN = '0-7356-1588-2'

사용자 정의 함수를 만들고 사용하여 xml 데이터 형식과 계산 열을 반환할 수 있습니다. 하지만 XML 계산 열에는 XML 인덱스를 만들 수 없습니다.

속성 테이블 만들기

XML 데이터에서 여러 값의 속성 중 일부를 하나 이상의 테이블로 승격시키고 해당 테이블에서 인덱스를 만들고 이를 사용하도록 쿼리를 다시 대상화할 수 있습니다. 일반적인 시나리오는 속성 중 일부에 대부분의 쿼리 작업이 포함되는 경우입니다. 사용할 수 있는 기능은 다음과 같습니다.

  • 다중 값 속성을 보유하도록 하나 이상의 테이블을 만듭니다. 테이블마다 하나의 속성을 저장하고 기본 테이블로 다시 조인하기 위해 속성 테이블에 있는 기본 테이블의 기본 키를 중복시키는 것이 편리할 수 있습니다.
  • 속성의 상대적 순서를 유지하려면 상대적 순서에 대해 개별 열을 사용해야 합니다.
  • 속성 테이블을 유지 관리하기 위해 XML 열에 트리거를 만듭니다. 트리거 내에서 다음 중 하나를 수행합니다.
    • nodes() 및 **value()**와 같은 xml 데이터 형식의 메서드를 사용하여 속성 테이블의 행을 삽입 및 삭제합니다.
    • 속성 테이블의 행을 삽입 및 삭제하기 위해 CLR(공용 언어 런타임)에 스트리밍 테이블 값 함수를 만듭니다.
    • 속성 테이블에 대한 SQL 액세스 및 기본 테이블의 XML 열에 대한 XML 액세스를 위한 쿼리를 작성하고 해당 기본 키를 사용하여 테이블 간 조인을 포함시킵니다.
예: 속성 테이블 만들기

이해를 돕기 위해 저자의 이름을 승격해야 한다고 가정해 보십시오. 책에는 한 명 이상의 저자가 있으므로 이름은 다중 값 속성입니다. 각 이름은 속성 테이블의 별개의 행에 저장됩니다. 기본 테이블의 기본 키는 역 조인을 위해 속성 테이블에 중복됩니다.

create table tblPropAuthor (propPK int, propAuthor varchar(max))
예: XML 인스턴스로부터 행 집합을 생성하기 위한 사용자 정의 함수 만들기

다음 테이블 값 함수 udf_XML2Table은 기본 키 값과 XML 인스턴스를 허용합니다. 이 함수는 <book> 요소에 대한 모든 저자의 이름을 검색하고 기본 키와 이름의 쌍인 행 집합을 반환합니다.

create function udf_XML2Table (@pk int, @xCol xml)
returns @ret_Table table (propPK int, propAuthor varchar(max))
with schemabinding
as
begin
      insert into @ret_Table 
      select @pk, nref.value('.', 'varchar(max)')
      from   @xCol.nodes('/book/author/first-name') R(nref)
      return
end
예: 속성 테이블을 채우기 위한 트리거 만들기

삽입 트리거는 속성 테이블에 행을 삽입합니다.

create trigger trg_docs_INS on T for insert
as
      declare @wantedXML xml
      declare @FK int
      select @wantedXML = xCol from inserted
      select @FK = PK from inserted

   insert into tblPropAuthor
   select * from dbo.udf_XML2Table(@FK, @wantedXML)

삭제 트리거는 삭제된 행의 기본 키 값에 따라 속성 테이블에서 행을 삭제합니다.

create trigger trg_docs_DEL on T for delete
as
   declare @FK int
   select @FK = PK from deleted
   delete tblPropAuthor where propPK = @FK

업데이트 트리거는 업데이트된 XML 인스턴스에 따라 속성 테이블에서 기존 행을 삭제하고 속성 테이블에 새 행을 삽입합니다.

create trigger trg_docs_UPD
on T
for update
as
if update(xCol) or update(pk)
begin
      declare @FK int
      declare @wantedXML xml
      select @FK = PK from deleted
      delete tblPropAuthor where propPK = @FK

   select @wantedXML = xCol from inserted
   select @FK = pk from inserted

   insert into tblPropAuthor 
      select * from dbo.udf_XML2Table(@FK, @wantedXML)
end
예: 저자의 이름이 "David"인 XML 인스턴스 찾기

XML 열에 쿼리를 만들 수 있습니다. 또는 속성 테이블에서 "David"라는 이름을 검색하고 기본 테이블에서 역 조인을 수행하여 XML 인스턴스를 반환할 수 있습니다. 예를 들면 다음과 같습니다.

SELECT xCol 
FROM     T JOIN tblPropAuthor ON T.pk = tblPropAuthor.propPK
WHERE    tblPropAuthor.propAuthor = 'David'
예: CLR 스트리밍 테이블 값 함수를 사용한 해결 방법

이 해결 방법은 다음 단계로 구성됩니다.

  1. ISqlReader를 구현하고 XML 인스턴스에 경로 식을 적용하여 스트리밍 테이블 값 출력을 생성하는 SqlReaderBase라는 CLR 클래스를 정의합니다.
  2. 어셈블리 및 Transact-SQL 사용자 정의 함수를 만들어서 CLR 클래스를 시작합니다.
  3. 속성 테이블을 유지 관리하기 위한 사용자 정의 함수를 사용하여 삽입, 업데이트 및 삭제 트리거를 정의합니다.

이렇게 하려면 먼저 스트리밍 CLR 함수를 만듭니다. xml 데이터 형식은 ADO.NET의 관리 클래스 SqlXml로 제공되며 XmlReader를 반환하는 CreateReader() 메서드를 지원합니다.

[!참고] 이 섹션의 예제 코드에서는 XPathDocument 및 XPathNavigator가 사용됩니다. 이를 통해 사용자는 모든 XML 문서를 메모리에 강제로 로드할 수 있습니다. 일부 큰 XML 문서를 처리하기 위해 응용 프로그램에서 비슷한 코드를 사용하는 경우 이 코드는 확장할 수 없습니다. 대신 메모리 할당을 적게 유지하고 가능한 모든 경우에 스트리밍 인터페이스를 사용합니다. 성능에 대한 자세한 내용은 Architecture of CLR Integration을 참조하십시오.

public class c_streaming_xml_tvf {
   public static ISqlReader streaming_xml_tvf 
(SqlXml xmlDoc, string pathExpression) {
      return (new TestSqlReaderBase (xmlDoc, pathExpression));
   }
}

// Class that implements ISqlReader
public class TestSqlReaderBase : ISqlReader {
XPathNodeIterator m_iterator;         
   public SqlChars FirstName;
// Metadata for current resultset
private SqlMetaData[] m_rgSqlMetaData;      

   public TestSqlReaderBase (SqlXml xmlDoc, string pathExpression) {   
      // Variables for XPath navigation
      XPathDocument xDoc;
      XPathNavigator xNav;
      XPathExpression xPath;
   
      // Set sql metadata
      m_rgSqlMetaData = new SqlMetaData[1];
      m_rgSqlMetaData[0] = new SqlMetaData ("FirstName",  
SqlDbType.NVarChar,50);   
   
      //Set up the Navigator
      if (!xmlDoc.IsNull)
          xDoc = new XPathDocument (xmlDoc.CreateReader());
      else
          xDoc = new XPathDocument ();
      xNav = xDoc.CreateNavigator();
      xPath = xNav.Compile (pathExpression);
      m_iterator = xNav.Select(xPath);
   }
   public bool Read() {
      bool moreRows = true;
      if (moreRows = m_iterator.MoveNext())
         FirstName = new SqlChars (m_iterator.Current.Value);
      return moreRows;
   }
}

그런 다음 CLR 함수 streaming_xml_tvf에 해당하는 Transact-SQL 사용자 정의 함수인 SQL_streaming_xml_tvf(표시 안 됨)와 어셈블리를 만듭니다. 행 집합 생성을 위해 테이블 값 함수인 CLR_udf_XML2Table을 정의하는 데 사용자 정의 함수가 사용됩니다.

create function CLR_udf_XML2Table (@pk int, @xCol xml)
returns @ret_Table table (FK int, FirstName varchar(max))
with schemabinding
as
begin
      insert into @ret_Table 
   select @pk, FirstName 
   FROM   SQL_streaming_xml_tvf (@xCol, '/book/author/first-name')
      return
end

마지막으로 "속성 테이블을 채우기 위한 트리거 만들기" 예에서 표시된 것과 같이 트리거를 정의하고 udf_XML2Table을 CLR_udf_XML2Table 함수로 바꿉니다. 다음 예에는 삽입 트리거가 표시됩니다.

create trigger CLR_trg_docs_INS on T for insert
as
   declare @wantedXML xml
   declare @FK int
   select @wantedXML = xCol from inserted
   select @FK = PK from inserted

   insert into tblPropAuthor
      select *
   from    dbo.CLR_udf_XML2Table(@FK, @wantedXML)

삭제 트리거는 비-CLR 버전과 동일합니다. 하지만 업데이트 트리거는 udf_XML2Table() 함수를 CLR_udf_XML2Table() 함수로 바꿉니다.

XML 스키마 컬렉션

XML 스키마 컬렉션은 관계형 스키마에 의해 범위가 지정되는 메타데이터 엔터티입니다. 여기에는 <xs:import>를 통해 연결되거나 연결되지 않을 수 있는 하나 이상의 XML 스키마가 포함됩니다. XML 스키마 컬렉션 내에 있는 개별 XML 스키마는 해당 대상 네임스페이스를 사용하여 식별됩니다.

XML 스키마 컬렉션은 CREATE XML SCHEMA COLLECTION(Transact-SQL) 구문을 사용하고 하나 이상의 XML 스키마를 제공하여 생성됩니다. ALTER XML SCHEMA COLLECTION(Transact-SQL) 구문을 사용하면 기존 XML 스키마에 더 많은 XML 스키마 구성 요소를 추가할 수 있으며 XML 스키마 컬렉션에 더 많은 스키마를 추가할 수 있습니다. XML 스키마 컬렉션은 SQL Server 2005에서 보안 모델을 사용하여 다른 SQL 개체와 같이 보호될 수 있습니다.

다중 형식화된 열

XML 스키마 컬렉션 C는 다중 XML 스키마에 따라 XML 열 xCol을 형식화합니다. 또한 DOCUMENT 및 CONTENT 플래그는 XML 트리 또는 조각이 각각 xCol 열에 저장될 수 있는지 여부를 지정합니다.

DOCUMENT의 경우 각 XML 인스턴스는 인스턴스에 있는 해당 최상위 요소의 대상 네임스페이스와 이에 따라 형식화되고 유효성이 검사되는 항목을 지정합니다. 반면에 CONTENT의 경우에는 각 최상위 요소가 C에 있는 대상 네임스페이스 중 하나를 지정할 수 있습니다. XML 인스턴스는 인스턴스에서 발생하는 모든 대상 네임스페이스에 따라 유효성이 검사되고 형식화됩니다.

스키마 발전

XML 스키마 컬렉션은 XML 열, 변수 및 매개 변수를 형식화하는 데 사용됩니다. 이 스키마 컬렉션은 XML 스키마 발전을 위한 메커니즘을 제공합니다. 이해를 돕기 위해 대상 네임스페이스가 BOOK-V1인 XML 스키마를 XML 스키마 컬렉션 C에 추가한다고 가정해 보십시오. C로 형식화된 XML 열인 xCol은 BOOK-V1 스키마에 해당하는 XML 데이터를 저장할 수 있습니다.

그런 다음 응용 프로그램에서 복합 유형 정의 및 최상위 요소 선언과 같은 새로운 스키마 구성 요소로 XML 스키마를 확장한다고 가정해 보십시오. 이러한 새 스키마 구성 요소는 BOOK-V1에 추가될 수 있으며 xCol 열에 있는 기존 XML 데이터를 다시 유효성 검사할 필요가 없습니다.

응용 프로그램에서 나중에 새로운 XML 스키마 버전을 제공하고 대상 네임스페이스 BOOK-V2를 선택한다고 가정하십시오. 이 XML 스키마는 C에 추가될 수 있습니다. XML 열은 BOOK-V1 및 BOOK-V2의 인스턴스를 모두 저장할 수 있으며 이러한 네임스페이스에 해당하는 XML 인스턴스에서 쿼리 및 데이터 수정을 수행할 수 있습니다.

XML 데이터 로드

SQL Server 2000에서 SQL Server 2005로 XML 데이터 전송

XML 데이터는 몇 가지 방식으로 SQL Server 2005로 전송할 수 있습니다. 예를 들면 다음과 같습니다.

  • SQL Server 2000 데이터베이스의 [n]text 또는 image 열에 데이터가 있으면 SQL Server 2005 Integration Services(SSIS)를 사용하여 테이블을 SQL Server 2005 데이터베이스로 가져올 수 있습니다. ALTER TABLE 문을 사용하여 열 유형을 XML로 바꿉니다.
  • bcp out을 사용하여 SQL Server 2000에서 데이터를 대량 복사한 다음 bcp in을 사용하여 데이터를 SQL Server 2005 데이터베이스로 대량 삽입할 수 있습니다.
  • SQL Server 2000 데이터베이스의 관계형 열에 데이터가 있는 경우 [n]text 열 및 행 식별자의 경우 기본 키 열(옵션)이 포함된 새 테이블을 만듭니다. 클라이언트측 프로그래밍을 사용하여 FOR XML로 서버에서 생성된 XML을 검색하고 이를 [n]text 열에 씁니다. 그런 다음 이전에 언급된 기술을 사용하여 데이터를 SQL Server 2005 데이터베이스에 전송합니다. SQL Server 2005 데이터베이스에 있는 XML 열로 XML을 직접 작성하도록 선택할 수 있습니다.
예: 열 유형을 XML로 변경

[n]text 또는 image 열의 유형(R 테이블의 XYZ)을 형식화되지 않은 XML로 변경한다고 가정해 보십시오. 다음 문은 이러한 유형의 변경을 수행합니다.

ALTER TABLE R ALTER COLUMN XYZ XML
  • 대상은 필요한 경우 XML 스키마 컬렉션을 지정하여 형식화된 XML일 수 있습니다.

XML 데이터 대량 로드

bcp와 같은 SQL Server의 대량 로드 기능을 사용하여 XML 데이터를 서버에 대량 로드할 수 있습니다. OPENROWSET을 사용하면 데이터를 파일에서 XML 열로 로드할 수 있습니다. 다음 예에서는 이러한 점을 보여 줍니다.

예: 파일로부터 XML 로드

이 예에서는 테이블 T에 행을 삽입하는 방법을 보여 줍니다. XML 열의 값은 C:\MyFile\xmlfile.xml 파일로부터 CLOB으로 로드되고 정수 열에는 값 10이 제공됩니다.

INSERT INTO T
SELECT 10, xCol
FROM    (SELECT *    
    FROM OPENROWSET (BULK 'C:\MyFile\xmlfile.xml', SINGLE_CLOB) 
 AS xCol) AS R(xCol)

텍스트 인코딩

SQL Server 2005는 XML 데이터를 유니코드(UTF-16)로 저장합니다. 서버에서 검색된 XML 데이터는 UTF-16 인코딩으로 출력됩니다. 다른 인코딩이 필요한 경우 검색된 데이터에서 필요한 변환을 수행해야 합니다. 일부 경우 XML 데이터는 다른 인코딩으로 표시될 수 있습니다. 이 경우 데이터 로드 중에 주의해야 합니다. 예를 들면 다음과 같습니다.

  • XML 텍스트가 유니코드(UCS-2, UTF-16)인 경우 문제 없이 이를 XML 열, 변수 또는 매개 변수에 할당할 수 있습니다.
  • 인코딩이 유니코드가 아니고 암시적인 경우 원본 코드 페이지로 인해 데이터베이스의 문자열 코드 페이지는 로드하려는 코드 지점과 호환되거나 동일해야 합니다. 필요한 경우 COLLATE를 사용합니다. 이러한 서버 코드 페이지가 없는 경우 명시적 XML 선언을 올바른 인코딩으로 추가해야 합니다.
  • 명시적 인코딩을 사용하려면 코드 페이지와 상호 작용이 없는 varbinary() 유형을 사용하거나 적합한 코드 페이지의 문자열 유형을 사용합니다. 그런 다음 데이터를 XML 열, 변수 또는 매개 변수에 할당합니다.
예: 인코딩을 명시적으로 지정

명시적 XML 선언 없이 **varchar(max)**로 저장된 XML 문서인 vcdoc가 있다고 가정해 보십시오. 다음 문은 "iso8859-1" 인코딩으로 XML 선언을 추가하고 XML 문서를 연결하고 결과를 **varbinary(max)**로 형변환하여 바이트 표현이 유지되도록 한 다음 마지막으로 XML로 형변환합니다. 이렇게 하면 XML 프로세서가 지정된 "iso8859-1" 인코딩에 따라 데이터를 구문 분석하고 문자열 값에 대한 해당 UTF-16 표현을 생성할 수 있습니다.

SELECT CAST( 
CAST (('<?xml version="1.0" encoding="iso8859-1"?>'+ vcdoc) AS VARBINARY (MAX)) 
 AS XML)

XQuery 및 유형 추론

Transct-SQL에 포함된 XQuery는 xml 데이터 형식을 쿼리하기 위해 지원되는 언어입니다. 이 언어는 Microsoft의 모든 주요 데이터베이스 공급업체가 참여한 가운데 W3C(World Wide Web Consortium)에서 개발 중에 있습니다. 여기에는 탐색 언어로 XPath 버전 2.0이 포함됩니다. 데이터 수정을 위한 언어 생성도 xml 데이터 형식으로 제공됩니다. SQL Server에서 지원되는 XQuery 생성, 함수 및 연산자에 대한 자세한 내용은 xml 데이터 형식에 대한 XQuery 함수를 참조하십시오.

오류 모델

컴파일 오류는 구문이 잘못된 XQuery 식 및 XML DML 문으로부터 반환됩니다. 컴파일 단계에서는 XQuery 식 및 DML 문의 정적 유형이 올바른지 여부를 확인하고 형식화된 XML에 대한 유형 추론을 위해 XML 스키마를 사용합니다. 유형 안전성 위반으로 인해 런타임에 식이 실패할 수 있는 경우 정적 유형 오류가 발생합니다. 정적 오류는 정수에 문자열을 추가하는 경우와 형식화된 데이터에 대해 존재하지 않는 노드를 쿼리하는 경우를 예로 들 수 있습니다.

W3C 표준에서 벗어나는 XQuery 런타임 오류는 빈 시퀀스로 변환됩니다. 이러한 시퀀스는 호출 컨텍스트에 따라 빈 XML 또는 NULL로 쿼리 결과에 전파될 수 있습니다.

올바른 유형으로 명시적으로 형변환하면 런타임 형변환 오류가 빈 시퀀스로 전송되더라도 사용자가 정적 오류를 해결할 수 있습니다.

다음 섹션에서는 유형 검사에 대해 자세히 설명합니다.

단일 항목 검사

단일 항목이 필요한 위치 단계, 함수 매개 변수 및 연산자는 컴파일러가 런타임 시 단일 항목이 보장되는지 여부를 확인할 수 없는 경우 오류를 반환합니다. 이 문제는 형식화되지 않은 데이터에서 자주 발생합니다. 예를 들어 특성 조회에는 단일 부모 요소가 필요합니다. 이를 위해서는 단일 부모 노드를 선택하는 서수만으로도 충분합니다. 특성 값 추출을 위한 node()-value() 조합의 평가에는 서수 사양이 필요하지 않을 수 있습니다. 이러한 내용은 다음 예에 표시되어 있습니다.

예: 알려진 단일 항목

이 예에서 nodes() 메서드는 각 <book> 요소에 대해 별개의 행을 생성합니다. <book> 노드에서 평가되는 value() 메서드는 @genre의 값을 추출하고 단일 항목 특성이 됩니다.

SELECT nref.value('@genre', 'varchar(max)') LastName
FROM   T CROSS APPLY xCol.nodes('//book') AS R(nref)

형식화된 XML의 유형 검사에는 XML 스키마가 사용됩니다. XML 스키마의 단일 항목으로 노드가 지정된 경우 컴파일러는 이 정보를 사용하며 오류가 발생하지 않습니다. 그렇지 않으면 단일 노드를 선택하는 서수가 필요합니다. 특히 /book//title에서와 같이 하위 항목 또는 자체 축(//)을 사용하면 XML 스키마에 지정되어 있더라도 <title> 요소에 대한 단일 항목 카디널리티 추론이 손실됩니다. 따라서 이를 (/book//title)[1]과 같이 다시 작성해야 합니다.

유형 검사를 위해서는 //first-name[1] 및 (//first-name)[1] 간의 차이점을 인식해야 합니다. 전자는 각 노드가 해당 형제 간의 가장 왼쪽에 있는 <first-name> 노드인 <first-name> 노드의 시퀀스를 반환합니다. 후자는 XML 인스턴스에서 문서 순서의 첫 번째 단일 <first-name> 노드를 반환합니다.

예: value() 사용

형식화되지 않은 XML 열에서 다음 쿼리를 실행하면 정적 컴파일 오류가 발생합니다. 그 이유는 **value()**에 첫 번째 인수로 단일 노드가 필요한데 런타임 시 하나의 <last-name> 노드만 발생하는지 여부를 컴파일러에서 확인할 수 없기 때문입니다.

SELECT xCol.value('//author/last-name', 'nvarchar(50)') LastName
FROM   T

다음은 고려할 수 있는 해결 방법입니다.

SELECT xCol.value('//author/last-name[1]', 'nvarchar(50)') LastName
FROM   T

하지만 이 해결 방법은 각 XML 인스턴스에 여러 <author> 노드가 발생할 수 있기 때문에 오류를 해결하지 않습니다. 다음과 같이 쿼리를 다시 작성하면 도움이 됩니다.

SELECT xCol.value('(//author/last-name/text())[1]', 'nvarchar(50)') LastName
FROM   T

이 쿼리는 각 XML 인스턴스에서 첫 번째 <last-name> 요소의 값을 반환합니다.

부모 축

노드 유형을 확인할 수 없는 경우 anyType이 됩니다. 이 유형은 다른 유형으로 암시적으로 형변환됩니다. 이러한 동작은 xCol.query('/book/@genre/../price')와 같은 부모 축을 사용하여 특히 탐색 중에 발생합니다. 부모 노드 유형은 anyType으로 확인됩니다. 요소는 XML 스키마의 anyType으로 정의되기도 합니다. 두 경우 모두 보다 정확한 유형 정보가 손실되면 정적 유형 오류가 자주 발생하며 특정 유형으로의 원자 값의 명시적 형변환이 필요합니다.

Data(), text() 및 string() 접근자

XQuery에는 노드로부터 형식화된 스칼라 값을 추출하는 fn:data() 함수, 텍스트 노드를 반환하는 노드 테스트 text() 및 노드의 문자열 값을 반환하는 fn:string() 함수가 있습니다. 이들 함수의 용도는 혼동될 수 있습니다. 다음은 SQL Server 2005에서 이러한 함수를 올바르게 사용하기 위한 지침입니다. XML 인스턴스 <age>12</age>는 설명을 위해 사용되었습니다.

  • 형식화되지 않은 XML: 경로 식 /age/text()는 텍스트 노드 "12"를 반환합니다. fn:data(/age) 함수는 문자열 값 "12"를 반환하고 fn:string(/age)도 "12"를 반환합니다.
  • 형식화된 XML: /age/text() 식은 간단한 형식화된 <age> 요소에 대해 정적 오류를 반환합니다. 반면에 fn:data(/age)는 정수 12를 반환하고 fn:string(/age)는 문자열 "12"를 반환합니다.

UNION 유형에 대한 함수 및 연산자

UNION 유형은 유형 검사로 인해 조심스럽게 처리해야 합니다. 다음 예에서는 두 가지 문제에 대해 설명합니다.

예: UNION 유형에 대한 함수

UNION 유형의 <r>에 대한 요소 정의를 고려하십시오.

<xs:element name="r">
<xs:simpleType>
   <xs:union memberTypes="xs:int xs:float xs:double"/>
</xs:simpleType>
</xs:element>

XQuery 컨텍스트 내에서 "평균" 함수인 fn:avg (//r)은 XQuery 컴파일러에서 fn:avg() 인수에 있는 <r> 요소에 대해 다른 유형(xs:int, xs:float 또는 xs:double)의 값을 추가할 수 없기 때문에 정적 오류를 반환합니다. 이 문제를 해결하려면 함수 호출을 fn:avg(for $r in //r return $r cast as xs:double ?)로 다시 작성합니다.

예: UNION 유형에 대한 연산자

더하기 연산('+')에는 정확한 유형의 피연산자가 필요합니다. 따라서 (//r)[1] + 1 식은 <r> 요소에 대한 앞의 유형 정의에서 설명한 정적 오류를 반환합니다. 한 가지 해결 방법은 함수 호출을 (//r)[1] cast as xs:int? +1(여기서 "?"는 0 또는 1 발생 횟수를 나타냄)로 다시 작성하는 것입니다. 모든 형변환은 런타임 오류의 결과로 빈 시퀀스를 발생시킬 수 있기 때문에 SQL Server 2005에는 "cast as"와 "?"가 필요합니다.

Value(), Nodes() 및 OpenXML()

SELECT 절에서 xml 데이터 형식에 여러 value() 메서드를 사용하여 추출된 값의 행 집합을 생성할 수 있습니다. nodes() 메서드는 추가 쿼리에 사용할 수 있는 선택된 각 노드에 대해 내부 참조를 생성합니다. nodes() 메서드와 value() 메서드를 조합하면 일부 행이 있고 해당 생성 시 사용된 경로 식이 복잡한 경우 행 집합을 더욱 효율적으로 생성할 수 있습니다.

nodes() 메서드는 특수한 xml 데이터 형식의 인스턴스를 생성하며 각 인스턴스에는 서로 다른 선택 노드에 대한 컨텍스트 집합이 있습니다. 이러한 종류의 XML 인스턴스는 query(), value(), nodes() 및 exist() 메서드를 지원하며 count(*) 집계에 사용될 수 있습니다. 다른 용도로 사용하면 오류가 발생합니다.

예: nodes() 사용

저자의 성과 이름을 추출한다고 가정해 보십시오. 이때 이름은 "David"가 아닙니다. 또한 이 정보를 FirstName 및 LastName의 두 열이 포함된 행 집합으로 추출합니다. nodes() 및 value() 메서드를 사용하면 다음과 같이 이 작업을 수행할 수 있습니다.

SELECT nref.value('(first-name/text())[1]', 'nvarchar(50)') FirstName,
       nref.value('(last-name/text())[1]', 'nvarchar(50)') LastName
FROM   T CROSS APPLY xCol.nodes('//author') AS R(nref)
WHERE  nref.exist('first-name[. != "David"]') = 1

이 예에서 nodes('//author')는 각 XML 인스턴스에 대한 <author> 요소의 참조 행 집합을 생성합니다. 저자의 성과 이름은 이러한 참조에 대해 value() 메서드를 평가하여 얻습니다.

SQL Server 2000는 **OpenXml()**을 사용하여 XML 인스턴스로부터 행 집합을 생성하는 기능을 제공합니다. 행 집합에 대한 관계형 스키마를 지정하고 XML 인스턴스 내의 값이 행 집합의 열로 매핑되는 방식을 지정할 수 있습니다.

예: xml 데이터 형식에서 OpenXml() 사용

다음에 표시된 것과 같이 **OpenXml()**을 사용하여 이전 예의 쿼리를 다시 작성할 수 있습니다. 이러한 작업은 각 XML 인스턴스를 XML 변수로 읽고 OpenXML을 여기에 적용하는 커서를 만들어서 수행합니다.

DECLARE name_cursor CURSOR
FOR
   SELECT xCol 
   FROM   T
OPEN name_cursor
DECLARE @xmlVal XML
DECLARE @idoc int
FETCH NEXT FROM name_cursor INTO @xmlVal

WHILE (@@FETCH_STATUS = 0)
BEGIN
   EXEC sp_xml_preparedocument @idoc OUTPUT, @xmlVal
   SELECT   *
   FROM   OPENXML (@idoc, '//author')
          WITH (FirstName  varchar(50) 'first-name',
                LastName   varchar(50) 'last-name') R
   WHERE  R.FirstName != 'David'

   EXEC sp_xml_removedocument @idoc
   FETCH NEXT FROM name_cursor INTO @xmlVal
END
CLOSE name_cursor
DEALLOCATE name_cursor

**OpenXml()**은 메모리 내 표현을 만들고 쿼리 프로세서 대신 작업 테이블을 사용합니다. 이 함수는 XQuery 엔진 대신 MSXML 버전 3.0의 XPath 버전 1.0 프로세서를 사용합니다. 작업 테이블은 동일 XML 인스턴스에 있는 경우에도 **OpenXml()**에 대한 여러 호출 간에 공유되지 않습니다. 이 때문에 확장성이 제한됩니다. **OpenXml()**을 사용하면 WITH 절이 지정되지 않은 경우 XML 데이터에 대한 Edge 테이블 형식에 액세스할 수 있습니다. 또한 별개의 "오버플로" 열에서 남아 있는 XML 값을 사용할 수 있습니다.

nodes() 및 value() 함수 조합은 XML 인덱스를 효율적으로 사용합니다. 그 결과 이러한 조합은 OpenXml보다 많은 확장성을 제공합니다.

행 집합으로부터 XML을 생성하기 위해 FOR XML 사용

새로운 TYPE 지시어로 FOR XML을 사용하여 행 집합으로부터 xml 데이터 형식의 인스턴스를 생성할 수 있습니다.

결과는 xml 데이터 형식의 열, 변수 또는 매개 변수에 할당할 수 있습니다. 또한 FOR XML은 계층적 구조를 생성하도록 중첩될 수 있습니다. 이로 인해 FOR XML EXPLICIT보다 중첩된 FOR XML이 작성하기에 더욱 편리하지만 중첩이 많은 계층에서는 성능이 저하될 수 있습니다. FOR XML은 또한 새로운 PATH 모드를 제공합니다. 이 새로운 모드는 열 값이 나타나는 XML 트리의 경로를 지정합니다.

새로운 FOR XML TYPE 지시어를 사용하여 SQL 구문에서 관계형 데이터에 대해 읽기 전용 XML 뷰를 정의할 수 있습니다. 이 뷰는 다음 예에서와 같이 SQL 문과 포함된 XQuery에서 쿼리할 수 있습니다. 또한 저장 프로시저에서 이러한 SQL 뷰를 참조할 수도 있습니다.

예: 생성된 xml 데이터 형식을 반환하는 SQL 뷰

다음 SQL 뷰 정의는 XML 열로부터 검색된 관계형 열, pk 및 책 저자에 대해 XML 뷰를 만듭니다.

CREATE VIEW V (xmlVal) AS
SELECT pk, xCol.query('/book/author')
FROM   T
FOR XML AUTO, TYPE

V 뷰에는 XML 유형의 단일 columnxmlVal이 있는 단일 행이 포함됩니다. 이 뷰는 일반적인 xml 데이터 형식 인스턴스와 같이 쿼리될 수 있습니다. 예를 들어 다음 쿼리는 이름이 "David"인 저자를 반환합니다.

SELECT xmlVal.query('//author[first-name = "David"]')
FROM   V

SQL 뷰 정의는 주석 지정 스키마를 사용하여 만든 XML 뷰와 일부 비슷합니다. 하지만 여기에는 중요한 차이가 있습니다. SQL 뷰 정의는 읽기 전용이며 포함된 XQuery로 조작되어야 합니다. XML 뷰는 주석 지정 스키마를 사용하여 생성됩니다. 또한 SQL 뷰는 XQuery 식을 적용하기 전에 XML 결과를 구체화하지만 XML 뷰의 XPath 쿼리는 기본 테이블에서 SQL 쿼리를 평가합니다.

비즈니스 논리 추가

비즈니스 논리를 여러 가지 방식으로 XML 데이터에 추가할 수 있습니다.

  • XML 데이터의 삽입 및 수정 중에 도메인 특정 제약 조건을 강화하도록 행 또는 열 제약 조건을 작성할 수 있습니다.
  • 열에서 값을 삽입 또는 업데이트할 때 발생되는 트리거를 XML 열에 작성할 수 있습니다. 이 트리거는 도메인 특정 유효성 검사 규칙을 포함하거나 속성 테이블을 채울 수 있습니다.
  • XML 값을 전달하는 관리 코드에 SQLCLR 함수를 작성하고 System.Xml 네임스페이스에서 제공되는 XML 처리 기능을 사용할 수 있습니다. 한 예는 XSL 변환을 XML 데이터에 적용하는 것입니다. 또는 XML을 하나 이상의 관리 클래스로 역직렬화하고 관리 코드를 사용하여 작업할 수 있습니다.
  • 비즈니스 요구에 맞게 XML 열에서 처리를 시작하는 Transact-SQL 저장 프로시저와 함수를 작성할 수 있습니다.
예: XSL 변환 적용

파일에 저장된 xml 데이터 형식 인스턴스와 XML 변환을 수락하고, XML 데이터에 변환을 적용하고, 변환된 XML을 결과로 반환하는 CLR 함수 **TransformXml()**를 고려해 보십시오. 다음은 C#으로 작성된 기초 함수입니다.

public static SqlXml TransformXml (SqlXml XmlData, string xslPath) {
   // Load XSL transformation
   XslCompiledTransform xform = new XslCompiledTransform();
   XPathDocument xslDoc = new XPathDocument (xslPath);
   xform.Load(xslDoc);

   // Load XML data 
   XPathDocument xDoc = new XPathDocument (XmlData.CreateReader());

   // Return the transformed value
   MemoryStream xsltResult = new MemoryStream();
   xform.Transform(xDoc, null, xsltResult);
   SqlXml retSqlXml = new SqlXml(xsltResult);
   return (retSqlXml);
}

어셈블리를 등록하고 사용자 정의 Transact-SQL 함수를 만든 후 다음 쿼리에서와 같이 **TransformXml()**에 해당하는 SqlXslTransform() 함수를 Transact-SQL로부터 호출할 수 있습니다.

SELECT SqlXslTransform (xCol, 'C:\MyFile\xsltransform.xsl')
FROM    T
WHERE  xCol.exist('/book/title/text()[contains(.,"custom")]') =1

쿼리 결과에는 변환된 XML의 행 집합이 포함됩니다.

SQLCLR은 XML 데이터를 테이블 또는 속성 승격으로 분해하고 System.Xml 네임스페이스에 있는 관리 클래스를 사용하여 XML 데이터를 쿼리할 수 있는 가능성을 확장합니다. 자세한 내용은 SQL Server 온라인 설명서 및 .NET Framework SDK 설명서를 참조하십시오.

도메인 간 쿼리

데이터가 관계형 및 xml 데이터 형식 열의 조합에 있는 경우 관계형 및 XML 데이터 처리를 조합하는 쿼리를 작성할 수 있습니다. 예를 들어 관계형 및 XML 열에 있는 데이터를 FOR XML을 사용하여 xml 데이터 형식 인스턴스로 변환하고 XQuery를 사용하여 쿼리할 수 있습니다. 또한 반대로 XML 값으로부터 행 집합을 생성하고 Transact-SQL을 사용하여 쿼리할 수 있습니다.

도메인 간 쿼리를 좀 더 편리하고 효율적으로 작성하는 방법은 XQuery 또는 XML DML 식 내에서 SQL 변수 또는 열의 값을 사용하는 것입니다.

  • sql:variable()을 사용하여 XQuery 또는 XML DML 식에 있는 SQL 변수 값을 사용할 수 있습니다.
  • sql:column()을 사용하여 XQuery 또는 XML DML 식에 있는 관계형 열의 값을 사용할 수 있습니다.

이러한 두 접근 방식을 사용하면 응용 프로그램에서 다음 예에 표시된 것처럼 쿼리를 매개 변수화할 수 있습니다. 하지만 XML 및 사용자 정의 유형은 sql:variable() 및 **sql:column()**에서 허용되지 않습니다.

예: sql:variable()을 사용하는 도메인 간 쿼리

다음 쿼리는 "예: xml 데이터 형식 메서드에 따른 계산 열 쿼리"에 표시된 쿼리의 수정 버전입니다. 다음 버전에서 이 특정 ISBN은 SQL 변수 @isbn을 사용하여 전달됩니다. 상수를 **sql:variable()**로 바꿈으로써 0-7356-1588-2인 ISBN 뿐만 아니라 다른 모든 ISBN을 검색하는 데 쿼리를 사용할 수 있습니다.

DECLARE @isbn varchar(20)
SET     @isbn = '0-7356-1588-2'
SELECT  xCol
FROM    T
WHERE   xCol.exist ('/book/@ISBN[. = sql:variable("@isbn")]') = 1

**sql:column()**을 비슷한 방식으로 사용하면 추가 이점이 있습니다. 비용 기반 쿼리 최적화 프로그램에서 결정되는 것과 같이 효율성을 위해 열에 대해 인덱스를 사용할 수 있습니다. 또한 계산 열에서 승격된 속성을 저장할 수 있습니다.

네이티브 XML 지원을 위한 카탈로그 뷰

카탈로그 뷰는 XML 사용에 대한 메타데이터 정보를 제공합니다. 이에 대한 일부 내용은 다음 섹션에서 설명됩니다.

XML 인덱스

XML 인덱스 항목은 인덱스 "type"이 3인 카탈로그 뷰 sys.indexes에 표시됩니다. 이름 열에는 XML 인덱스의 이름이 포함됩니다.

XML 인덱스는 또한 카탈로그 뷰 sys.xml_indexes에 기록됩니다. 여기에는 sys.indexes의 모든 열과 XML 인덱스에 유용한 특정 열이 포함됩니다. secondary_type 열에 있는 NULL 값은 기본 XML 인덱스를 나타냅니다. 'P', 'R' 및 'V' 값은 각각 PATH, PROPERTY 및 VALUE 보조 XML 인덱스를 나타냅니다.

XML 인덱스의 공간 사용은 sys.dm_db_index_physical_stats 테이블 값 함수에서 찾을 수 있습니다. 이 함수는 모든 인덱스 유형에 대해 사용된 디스크 페이지 수, 평균 행 크기(바이트) 및 레코드 수와 같은 정보를 제공합니다. 여기에는 XML 인덱스도 포함됩니다. 이 정보는 각 데이터베이스 파티션에서 사용할 수 있습니다. XML 인덱스는 기본 테이블과 동일한 파티션 구성표 및 파티션 함수를 사용합니다.

XML 스키마 컬렉션 검색

XML 스키마 컬렉션은 sys.xml_schema_collections 카탈로그 뷰에 열거됩니다. XML 스키마 컬렉션 "sys"는 시스템에 의해 정의됩니다. 여기에는 명시적으로 로드할 필요 없이 모든 사용자 정의 XML 스키마 컬렉션에서 사용할 수 있는 미리 정의된 네임스페이스가 포함됩니다. 이 목록에는 xml, xs, xsi, fn 및 xdt에 대한 네임스페이스가 포함됩니다. 두 개의 다른 카탈로그 뷰는 각 XML 스키마 컬렉션 내에서 모든 네임스페이스를 열거하는 sys.xml_schema_namespaces와 각 XML 스키마 내에서 모든 XML 스키마 구성 요소를 열거하는 sys.xml_components입니다.

기본 제공 함수인 XML_SCHEMA_NAMESPACE, schemaName, XmlSchemacollectionName, namespace-uri는 xml 데이터 형식의 인스턴스를 생성합니다. 이 인스턴스에는 미리 정의된 XML 스키마를 제외하고 XML 스키마 컬렉션에 포함된 스키마에 대한 XML 스키마 조각이 들어 있습니다.

XML 스키마 컬렉션의 내용은 다음과 같은 방식으로 열거할 수 있습니다.

  • XML 스키마 컬렉션에 적합한 카탈로그 뷰에 Transact-SQL 쿼리를 작성합니다.
  • 기본 제공 함수 **XML_SCHEMA_NAMESPACE()**를 사용합니다. 이 함수의 출력에 xml 데이터 형식 메서드를 적용할 수 있습니다. 하지만 기본 XML 스키마는 수정할 수 없습니다.

이러한 내용은 다음 예에 설명되어 있습니다.

예: XML 스키마 컬렉션에 XML 네임스페이스 열거

XML 스키마 컬렉션 "myCollection"에 대해 다음 쿼리를 사용합니다.

SELECT XSN.name
FROM    sys.xml_schema_collections XSC JOIN sys.xml_schema_namespaces XSN
    ON (XSC.xml_collection_id = XSN.xml_collection_id)
WHERE    XSC.name = 'myCollection'
예: XML 스키마 컬렉션의 내용 열거

다음 문은 관계형 스키마 dbo 내에 있는 XML 스키마 컬렉션 "myCollection"의 내용을 열거합니다.

SELECT XML_SCHEMA_NAMESPACE (N'dbo', N'myCollection')

컬렉션 내의 개별 XML 스키마는 **XML_SCHEMA_NAMESPACE()**에 대한 세 번째 인수로 대상 네임스페이스를 지정하여 xml 데이터 형식의 인스턴스로 가져올 수 있습니다. 이는 다음 예에서 확인할 수 있습니다.

예: XML 스키마 컬렉션으로부터 지정된 스키마 출력

다음 문은 관계형 스키마 dbo 내에 있는 XML 스키마 컬렉션 "myCollection"으로부터 대상 네임스페이스가 "https://www.microsoft.com/books"인 XML 스키마를 출력합니다.

SELECT XML_SCHEMA_NAMESPACE (N'dbo', N'myCollection', 
N'https://www.microsoft.com/books')

XML 스키마 쿼리

XML 스키마 컬렉션에 로드한 XML 스키마를 다음과 같은 방식으로 쿼리할 수 있습니다.

  • XML 스키마 네임스페이스에 대한 카탈로그 뷰에서 Transact-SQL 쿼리를 작성합니다.
  • xml 데이터 형식의 열이 포함된 테이블을 만들어서 XML 스키마를 저장하고 이를 XML 유형의 시스템으로 로드합니다. xml 데이터 형식의 메서드를 사용하여 XML 열을 쿼리할 수 있습니다. 또한 이 열에서 XML 인덱스를 작성할 수 있습니다. 하지만 이 접근 방식에서는 응용 프로그램이 XML 열에 저장된 XML 스키마와 XML 유형 시스템 간의 일관성을 유지 관리해야 합니다. 예를 들어 XML 유형 시스템으로부터 XML 스키마 네임스페이스를 삭제하면 일관성 유지를 위해 테이블에서도 삭제해야 합니다.

참고 항목

참조

서버에서 XML 스키마 컬렉션 관리
xml 데이터 형식에 대한 XQuery 함수

개념

xml 데이터 형식

관련 자료

sys.dm_db_index_physical_stats
전체 텍스트 검색 소개

도움말 및 정보

SQL Server 2005 지원 받기