기술자료

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

Microsoft SQL Server 2005의 XML 지원

작성자
dataonair
작성일
2000-01-01 00:00
조회
443



Microsoft SQL Server 2005의 XML 지원

Shankar Pal
Mark Fussell
Irwin Dolobowsky
Microsoft Corporation

2005년 5월

적용 대상:
Microsoft SQL Server

이 기사에서는 SQL Server 2005에서 기본 제공되는 XML 지원에 대해 설명합니다. .NET Framework 2.0 및 네이티브 코드의 클라이언트 쪽 프로그래밍 지원(예: OLEDB 및 SQLXML)과 XML 지원이 통합되는 방법에 대해 구체적으로 살펴봅니다.

목차

소개
XML 저장소 사용을 가속화하는 시나리오
SQL Server 2005의 서버 쪽 XML 처리
SQL Server 2005의 클라이언트 쪽 XML 처리
결론

소개

XML(eXtensible Markup Language)은 데이터 표현을 위한 플랫폼에 독립적인 형식으로 널리 채택되어 왔습니다. XML은 B2B 응용 프로그램이나 워크플로 상황에서와 같이 느슨하게 결합된 개별 시스템 사이에 정보를 교환하는 데 유용하게 사용됩니다. 데이터 교환은 XML 기술의 주요 원동력이었습니다.

XML은 반구조적 및 구조화되지 않은 데이터를 모델링하기 위해 엔터프라이즈 응용 프로그램에 점점 더 널리 사용되고 있습니다. XML이 적용되는 한 예로 문서 관리를 들 수 있습니다. 전자 메일과 같은 문서는 기본적으로 반구조적입니다. 문서가 데이터베이스 서버에 XML로 저장될 경우 문서 내용, 특정 내용 쿼리(예: 제목에 "백그라운드"라는 단어가 포함된 섹션 찾기) 및 문서 집계에 기초하여 문서를 검색하는 강력한 응용 프로그램을 개발할 수 있습니다. XML을 생성하고 사용하는 응용 프로그램이 증가함에 따라 이러한 시나리오는 실현 가능성이 점차 커지고 있습니다. 예를 들어, Microsoft Office 2003 시스템에서는 Word, Excel, Visio 및 Infopath 문서를 XML 태그로 생성할 수 있습니다.

XML 데이터에 관계형 데이터베이스를 사용하는 이유

  • XML 데이터를 관계형 데이터베이스에 저장하면 데이터 관리 및 쿼리 처리에 이점이 있습니다. SQL Server는 XML 데이터를 쿼리 및 수정하도록 확장된 관계형 데이터를 능가하는 강력한 쿼리 및 데이터 수정 기능을 제공합니다. 따라서 비용 기반 최적화 및 데이터 저장소 영역에서와 마찬가지로 이전 릴리스에 대한 투자를 계속 활용할 수 있습니다. 예를 들어, 잘 알려져 있는 관계형 데이터베이스의 인덱싱 기술은 XML 데이터 인덱싱이 가능하도록 확장되었기 때문에 비용 기반 결정을 사용하여 쿼리를 최적화할 수 있습니다.

  • XML 데이터는 기존 관계형 데이터 및 SQL 응용 프로그램과 상호 작용할 수 있으므로 데이터 모델링 요구가 증가할 경우 기존 응용 프로그램을 중단하지 않으면서 XML을 시스템에 도입할 수 있습니다. 또한 데이터베이스 서버는 XML 데이터 관리를 위한 관리 기능을 제공합니다(예: 백업, 복구 및 복제).

  • 이러한 기능으로 인해 SQL Server 2005 내에서 증가하는 XML 사용을 충족하는 네이티브 XML 지원의 요구가 점차 높아졌습니다. SQL Server 2005의 XML 지원은 엔터프라이즈 응용 프로그램 개발에 도움을 줄 것입니다.

  • 다음 절에서는 SQL Server 2000 및 2005의 XML 지원에 대한 개요를 제공하고 XML 사용을 가속화하는 몇 가지 시나리오를 설명하며 서버 쪽 및 클라이언트 쪽 XML 기능 집합에 대해 구체적으로 살펴봅니다.

SQL Server 2000의 XML 지원

이 섹션에서는 SQL Server 2000과 SQLXML 클라이언트 쪽 프로그래밍 플랫폼의 후속 웹 릴리스에서 제공되는 XML 지원에 대해 간략하게 설명합니다. 이러한 XML 지원은 관계형 데이터 모델과 XML 데이터 모델 사이에서 데이터를 매핑하기 위한 풍부한 지원을 제공합니다.

서버 쪽 지원

서버에서 XML 데이터는 SELECT 문의 FOR XML 절을 사용하여 테이블 및 쿼리 결과에서 생성될 수 있습니다. 이 방법은 데이터 교환 및 웹 서비스 응용 프로그램에 이상적입니다. FOR XML과 반대되는 것은 OpenXML이라고 부르는 관계형 행 집합 생성기 함수입니다. OpenXML은 XPath 1.0 식을 평가하여 XML 데이터에서 행 집합 열로 값을 추출합니다. OpenXML은 들어오는 XML 데이터를 테이블에 분산시키거나 쿼리를 위해 T-SQL 언어를 사용하는 응용 프로그램에 사용됩니다.

클라이언트 쪽 지원

SQL Server 2000에 대한 클라이언트 프로그래밍 지원을 SQLXML (영문)이라고 합니다. 이 기술의 핵심은 XML 스키마와 관계형 테이블 사이의 양방향 매핑을 의미하는 XML 뷰입니다. 나중에 웹 릴리스에 XSD 지원이 추가되기는 했지만 SQL Server 2000은 XDR 스키마 매핑만 지원합니다. 기본 테이블에서 경로 식을 SQL 쿼리로 변환하기 위해 매핑이 사용되고 쿼리 결과가 XML 결과로 패키지화되는 XPath 1.0의 하위 집합을 사용한 쿼리가 XML 뷰에서 허용됩니다.

또한 SQLXML을 사용하면 동적 섹션을 사용하여 XML 문서를 작성할 수 있는 XML 템플릿을 만들 수 있습니다. XML 문서에서는 매핑 쿼리 위에 FOR XML 쿼리 및/또는 XPath 1.0 식을 포함할 수 있습니다. XML 템플릿이 실행되면 쿼리 블록이 쿼리 결과로 바뀝니다. 이러한 방법을 사용하면 일부 정적 콘텐츠 및 데이터 기반의 동적 콘텐츠로 XML 문서를 만들 수 있습니다.

SQL Server 2000에는 다음 두 가지 기본 방법으로 SQLXML 기능에 액세스할 수 있습니다.

  • SQLXMLOLEDB 공급자- SQLXMLOLEDB 공급자는 ADO를 통해 Microsoft SQLXML 기능을 제공하는 OLE DB 공급자입니다.

  • HTTP 액세스- SQL Server 2000의 SQLXML 기능은 SQLXML ISAPI 필터를 사용하여 HTTP를 통해 액세스할 수도 있습니다. 제공되는 구성 도구를 사용하면 들어오는 요청을 수신하여 HTTP를 통해 XML 뷰에서 XML 템플릿, FOR XML 및 XPath 1.0 문을 실행하도록 웹 사이트를 설정할 수 있습니다.
XML 지원의 제한 사항

서버 및 클라이언트 프로그래밍 플랫폼은 테이블 형식 데이터와 XML 데이터 사이의 매핑에 기초하여 XML 데이터 생성 및 사용에 대한 풍부한 지원을 제공합니다. 또한 아주 잘 구조화된 XML 데이터도 이러한 지원을 통해 처리됩니다. SQLXML에서 쿼리 언어는 XPath 1.0의 하위 집합이며 몇 가지 제한 사항을 갖고 있습니다. 예를 들어, 하위 축(// 연산자)이 지원되지 않으므로 특정 솔루션을 개발하는 과정에 제한을 받게 됩니다. 또한 문서 관리와 같은 작업에서 필수적인 요소인 XML 문서 순서가 유지되지 않습니다. 이외에도 재귀적 XML 스키마가 지원되지 않습니다. 이러한 제한에도 불구하고 클라이언트 SQLXML 및 서버 XML 기능은 응용 프로그램 개발에서 널리 사용되어 왔습니다. SQL Server 2005는 이러한 제한을 대부분 해결하고 관계형 XML 교환 기능을 확장하며 네이티브 XML 지원을 제공합니다.

SQL Server 2005의 XML 지원 개요

이 섹션에서는 .NET Framework V2.0 및 네이티브 클라이언트 액세스 지원(예: OLE DB)을 통해 보완된 SQL Server 2005의 새로운ML 데이터 형식

XML 데이터 모델이 갖고 있는 고유한 특징으로 인해 관계형 데이터 모델에 매핑하는 것이 불가능하지는 않지만 매우 어렵습니다. XML 데이터는 재귀적일 수 있는 계층적 구조를 가지며 관계형 데이터베이스는 계층적 데이터(외래 키 관계로 모델링된)에 대한 지원이 취약합니다. 문서 순서는 XML 인스턴스의 본질적인 속성이며 쿼리 결과에서 유지되어야 합니다. 이는 순서가 지정되지 않은 관계형 데이터와 다른 점이며 순서를 적용하기 위해서는 추가 순서 지정 열이 필요합니다. XML 데이터를 다수의 테이블로 분해하는 실제 XML 스키마의 경우 쿼리 도중에 결과를 재결합하는 것은 많은 비용이 필요합니다.

SQL Server 2005에는 XML이라고 부르는 네이티브 데이터 형식이 도입되었습니다. 사용자는 관계형 열 외에 XML 형식의 열을 하나 이상 가진 테이블을 만들 수 있습니다. 또한 XML 변수와 매개 변수도 허용됩니다. 문서 순서나 재귀적 구조와 같은 XML 모델 특징을 더 확실하게 지원하기 위해 XML 값은 대규모 이진 개체(BLOB)로 내부 형식에 저장됩니다.

SQL Server 2005는 W3C XML 스키마를 메타데이터로 관리하기 위한 방법으로 XML 스키마 컬렉션을 제공합니다. XML 데이터 형식을 XML 스키마 컬렉션과 연관시켜 XML 인스턴스에서 스키마 제약 조건을 적용할 수 있습니다. XML 데이터가 XML 스키마 컬렉션과 연관된 경우에는 형식있는 XML이라고 하고 그렇지 않은 경우에는 형식없는 XML이라고 합니다. 형식있는 XML과 형식없는 XML은 둘 다 단일 프레임워크 안에 포함되고 XML 데이터 모델이 유지되며 쿼리 처리는 XML 의미를 적용합니다. 이러한 목적을 위해 기본 관계형 인프라가 광범위하게 사용됩니다. 기본 관계형 인프라는 관계형 데이터와 XML 데이터 간에 상호 운용성을 지원하여 XML 기능이 더 널리 채택되도록 합니다.

XML 데이터 형식 쿼리 및 데이터 수정

XML 인스턴스는 T-SQL SELECT 문을 사용하여 검색할 수 있습니다. XML 인스턴스를 쿼리 및 수정하기 위해 XML 데이터 형식에 대한 5개의 메서드가 기본적으로 제공됩니다.

XML 데이터 형식 메서드에는 현재 최종 심의 단계에 있는 W3C 표준 언어 Xquery를 사용할 수 있으며 탐색 언어인 XPath 2.0이 포함되어 있습니다. 또한 하위 트리 추가 또는 삭제, 스칼라 값 업데이트 등과 같은 XML 데이터 수정을 위해 언어를 사용할 수 있습니다. 포함된 XQuery 및 데이터 수정 언어는 다양한 기능과 함께 사용되어 XML 데이터 조작을 위한 풍부한 지원을 제공합니다.

XQuery 형식 시스템은 W3C XML 스키마 형식 시스템과 연계됩니다. 대부분의 SQL 형식은 XQuery 형식 시스템과 호환됩니다(예: 10진수). 몇 가지 형식(예: xs:duration)은 내부 형식에 저장되며 XQuery 형식 시스템과 호환되도록 적절하게 해석됩니다.

컴파일 단계에서는 XQuery 식과 데이터 수정 문의 정적 형식 정확성을 검사하고 형식있는 XML 경우에 형식 참조를 위해 XML 스키마가 사용됩니다. 형식 안전 위반으로 인해 런타임에 식이 실패할 경우 정적 형식 오류가 발생합니다.

XML 인덱싱

쿼리 실행은 런타임에 각 XML 인스턴스를 처리합니다. XML 값의 크기가 크고 테이블에 있는 다수의 행에서 쿼리가 평가될 때마다 이 방법은 많은 비용이 듭니다. 결과적으로 쿼리 속도를 높이기 위해 XML 열을 인덱싱하는 메커니즘이 제공됩니다.

관계형 데이터를 인덱싱하기 위해 B+ 트리가 광범위하게 사용되어 왔습니다. XML 열의 기본 XML 인덱스는 열에 있는 XML 인스턴스의 모든 태그, 값 및 경로에서 B+ 트리 인덱스를 만듭니다. 이 방법을 통해 문서 순서와 문서 구조를 유지하면서 효율적으로 XML 데이터에 대한 쿼리를 평가하고 B+ 트리에서 XML 결과를 리어셈블할 수 있습니다.

일반적으로 발생하는 다른 클래스의 쿼리 실행 속도를 높이기 위해 XML 열에 보조 XML 인덱스를 만들 수 있습니다. 경로 기반 쿼리에 대한 PATH 인덱스, 속성 모음 시나리오에 대한 PROPERTY 인덱스, 값 기반 쿼리에 대한 VALUE 인덱스 등이 이러한 보조 XML 인덱스입니다.

XML 스키마 처리

서로 관련되거나(<xs:import> 사용) 관련되지 않을 수 있는 XML 스키마 컬렉션에 따라서 XML 열, 변수 및 매개 변수를 선택적으로 형식화할 수 있습니다. 형식있는 각 XML 인스턴스는 자신이 따르는 XML 스키마 컬렉션에서 대상 네임스페이스를 지정합니다. 데이터베이스 엔진은 데이터 할당 및 수정 도중에 XML 스키마에 따라 인스턴스의 유효성을 검사합니다.

XML 스키마 정보는 저장소 및 쿼리 최적화에 사용됩니다. 형식 있는 XML 인스턴스는 XML 인덱스에서와 같이 내부 이진 표현으로 형식 있는 값을 포함합니다. 따라서 형식 있는 XML 데이터를 효율적으로 처리할 수 있습니다.

관계형 및 XML 통합

사용자는 관계형 데이터와 XML 데이터를 동일한 데이터베이스에 저장할 수 있습니다. 간단하게 말해서 데이터베이스 엔진은 관계형 데이터 모델 외에 XML 데이터 모델을 적용하는 방법을 알고 있습니다. 관계형 데이터와 SQL 응용 프로그램은 SQL Server 2005로 업그레이드한 후에도 계속 정상적으로 작동합니다. 파일과 텍스트 또는 이미지 열에 상주하는 XML 데이터는 서버의 XML 데이터 형식 열로 이동할 수 있습니다. XML 데이터 형식 메서드를 사용하여 XML 열을 인덱싱, 쿼리 및 수정할 수 있습니다.

데이터베이스는 XML 처리를 위해 저장소 엔진 및 쿼리 프로세스와 같은 기존의 관계형 인프라 및 엔진 구성 요소를 사용합니다. 예를 들어 XML 인덱스가 B+트리를 만들고 실행 계획 출력에서 쿼리 계획을 볼 수 있습니다. 관계형 프레임워크에 통합되는 백업/복원 및 복제와 같은 데이터 관리 기능을 XML 데이터에서 사용할 수 있습니다. 마찬가지로 데이터 미러링 및 스냅샷 격리와 같은 새로운 데이터 관리 기능은 XML 데이터 형식과 함께 작동하여 완벽한 사용자 경험을 제공합니다.

구조적 데이터는 테이블 및 관계형 열에 저장되어야 합니다. 응용 프로그램에서 세밀하게 조정된 데이터의 쿼리와 수정을 수행해야 하는 경우 XML을 사용하는 반구조적 및 태그 데이터에는 XML 데이터 형식이 적합합니다.

FOR XML 및 OpenXML 향상

기존 FOR XML 기능은 여러 방법으로 향상되었습니다. 향상된 FOR XML 기능은 XML 데이터 형식 인스턴스 및 기타 새로운 SQL 형식(예: [n]varchar(max))에서 작동합니다. 향상된 FOR XML 기능에 대한 자세한 내용은 [4]에서 확인할 수 있습니다.

새로운 TYPE 지시문은 XML 데이터 형식 메서드를 사용하여 XML 열, 변수 또는 매개 변수에 할당하거나 쿼리할 수 있는 XML 데이터 형식 인스턴스를 생성합니다. 이 기능을 통해 SELECT ... FOR XML TYPE 문을 중첩할 수 있게 합니다.

PATH 모드는 열 값이 표시되어야 하는 XML 트리의 경로를 사용자가 지정할 수 있게 하며 앞서 언급한 중첩과 함께 FOR XML EXPLICIT보다 간편하게 작성할 수 있습니다.

ELEMENTS와 함께 사용되는 XSINIL 지시문은 xsi:nil="true" 특성을 가진 요소에 NULL을 매핑합니다. 또한 새로운 ROOT 지시문을 사용하면 모든 모드의 FOR XML에서 루트 노드를 지정할 수 있습니다. 새 XMLSCHEMA 지시문은 XSD 인라인 스키마를 생성합니다. 또한 SQL Server 2005의 FOR XML을 사용하면 FOR XML RAW 모드에서 기본 <row>를 대체하기 위한 요소 이름을 지정할 수 있습니다.

향상된 OpenXML 기능 행 집합에서 XML 및 새 SQL 형식 열을 생성합니다.

XML 데이터 형식에 대한 클라이언트 액세스

클라이언트는 여러 방법으로 서버의 XML 데이터에 액세스할 수 있습니다. ODBC 및 OLE DB를 사용하는 네이티브 SQL 클라이언트 액세스는 XML 데이터 형식을 유니코드 문자열로 제공합니다. 또한 OLE DB는 유니코드 데이터를 스트리밍하기 위해 XML 데이터 형식에 대한 IsequentialStream 액세스를 제공합니다.

.NET Framework V2.0의 ADO.NET을 통해 관리되는 액세스는 SqlXml이라고 부르는 새 클래스로 XML 데이터를 제공합니다. 이 클래스는 반환된 XML을 읽기 위해 XmlReader 인스턴스를 반환하는 CreateReader()라는 메서드를 지원합니다. 마찬가지로 데이터 집합은 XML 문서로 편집하여 다시 SQL Server에 저장할 수 있는 중간 계층의 열에 XML 데이터 형식의 인스턴스를 로드할 수 있습니다. 두 가지 방법 중 하나로 SQL 쿼리를 서버에 대해 실행함으로써 중간 계층에서 조작하기 위해 XML 열을 검색할 수 있습니다.

SQL Server 2005에서 HTTP 종점에 대한 SOAP 직접 액세스를 사용하여 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 태그가 포함된 문서는 Office 2003과 같은 도구를 사용하여 작성하는 일이 점점 더 간편해지고 있습니다. 이러한 XML 문서는 XML 열에 저장하고 인덱싱, 쿼리 및 업데이트할 수 있습니다. 따라서 개발자는 네이티브 XML 지원을 사용하여 더 많은 것을 할 수 있습니다.

SQL Server 2005의 서버 쪽 XML 처리

SQL Server 2005에서는 관계형 데이터와 XML 데이터를 저장할 수 있는 하나의 데이터베이스를 제공하는 지원 방법이 사용됩니다.

XML 데이터 형식

유용한 CREATE TABLE 문을 사용하여 XML 열이 있는 테이블을 만들 수 있습니다. 그런 다음 특수한 방법으로 XML 열을 인덱싱할 수 있습니다.

형식없는 XML

SQL Server 2005 XML 데이터 형식은 ISO SQL-2003 표준 XML 데이터 형식을 구현합니다. 따라서 올바른 형식의 XML 1.0 문서뿐만 아니라 텍스트 노드와 임의 개수의 최상위 요소가 포함된 소위 XML 콘텐츠 단편도 저장할 수 있습니다. 데이터가 올바른 형식을 가지는지 검사되며(XML 데이터 형식이 XML 스키마에 바인딩될 필요는 없음) 올바른 형식이 아닌 데이터는 거부됩니다.

스키마가 미리 알려지지 않아서 매핑 기반 솔루션이 불가능한 경우에 형식없는 XML이 유용합니다. 또한 스키마가 알려져 있지만 관계형 데이터로의 매핑 모델이 매우 복잡하고 유지 관리하기 힘들거나 여러 스키마가 존재하며 외부 요구 사항에 기초하여 이러한 스키마가 나중에 데이터에 바인딩될 경우에도 형식없는 XML이 유용합니다.

예제: 테이블의 형식없는 XML 열

다음 문은 정수 기본 키 "pk" 와 형식없는 XML 열 "xCol"을 사용하여 "docs"라는 테이블을 만듭니다.

CREATE TABLE docs (pk INT PRIMARY KEY, xCol XML not null)

또한 기본 키가 있거나 없는 둘 이상의 XML 또는 관계형 열을 사용하여 테이블을 만들 수 있습니다.

형식있는 XML

XML 스키마 컬렉션에 XML 데이터를 설명하는 XML 스키마가 있을 경우 XML 스키마 컬렉션을 XML 열과 연관시켜 형식있는 XML을 생성할 수 있습니다. XML 스키마는 데이터의 유효성을 검사하고 쿼리 및 데이터 수정 문의 컴파일 도중에 형식없는 XML보다 정확한 형식 검사를 수행하며 저장소 및 쿼리 처리를 최적화하는 데 사용됩니다.

형식있로 지정할 수 있는 XML 문서나 콘텐츠를 저장할 수 있습니다(각각 DOCUMENT 또는 CONTENT 옵션으로 지정할 수 있으며 기본값은 CONTENT). 또한 XML 스키마 컬렉션을 제공해야 합니다. 각 XML 인스턴스에 정확하게 하나의 최상위 요소가 있을 경우 DOCUMENT를 지정하고 그렇지 않을 경우에는 CONTENT를 사용합니다. 쿼리 컴파일러는 형식 검사에서 DOCUMENT 플래그를 사용하여 싱글톤(singleton) 최상위 요소를 유추합니다.

예제: 테이블의 형식있는 XML 열

XML 열, 변수 및 매개 변수는 XML 스키마 컬렉션에 바인딩될 수 있습니다(자세한 내용과 예제는 이 기사의 뒤에 나오는 "XML 스키마 처리" 절 참조). MyCollection이 이러한 컬렉션 중 하나의 이름이라고 가정해 보십시오. 아래 문은 myCollection을 사용하여 형식화된 XML 열 Document가 있는 XmlCatalog 테이블을 만듭니다. 또한 단순히 XML 문서가 아니라 XML 단편을 허용하기 위해 형식있는 XML 열이 지정됩니다.

CREATE TABLE XmlCatalog (
ID INT PRIMARY KEY,
Document XML(CONTENT myCollection))

XML 데이터 형식 열 제약

  • XML 열을 형식화하는 것 외에도 형식 있는/없는 XML 데이터 형식 열에서 관계형(열 또는 행) 제약 조건을 사용할 수 있습니다. 대부분의 SQL 제약 조건은 XML 열에도 적용할 수 있지만 XML 데이터 형식 인스턴스는 비교할 수 없기 때문에 UNIQUE, PRIMARY KEY 및 FOREIGN KEY 제약 조건은 예외입니다. 따라서 XML 열을 널을 허용하거나 허용하지 않도록 지정하고 기본 값을 제공하며 열에서 CHECK 제약 조건을 정의할 수 있습니다. 예를 들어, 형식없는 XML 열은 저장된 XML 인스턴스가 XML 스키마를 따른다는 것을 확인하기 위해 CHECK 제약 조건을 가질 수 있습니다.
다음 상황에서 제약 조건을 사용합니다.
  • 비즈니스 규칙을 XML 스키마로 표현할 수 없습니다. 예를 들어, 꽃 가게의 배송 주소는 가게 위치로부터 50마일 이내에 있어야 하는데 이것을 XML 열에서 제약 조건으로 작성할 수 있습니다. 이 제약 조건은 XML 데이터 형식 메서드를 포함할 수 있습니다.

  • 테이블의 다른 XML 열이나 비 XML 열이 제약 조건에 포함됩니다. XML 인스턴스에 있는 고객의 ID(/Customer/@CustId)를 적용하여 정수 CustomerID 열의 값을 일치시키는 것을 예로 들 수 있습니다.

예제: XML 열 제약

  • <book>의 <author>가 서로 다른 <last-name>과 <first-name>을 갖고 있는지 확인하려면 다음 CHECK 제약 조건 CK_name을 지정합니다. XML 데이터 형식 메서드는 사용자 정의 함수 내에서 제공되어야 하며 이를 위해 udf_Check_Names()가 사용됩니다.

CREATE FUNCTION udf_Check_Names (@xmlData XML)
RETURNS int AS
BEGIN
RETURN (SELECT @xmlData.exist('/book/author[first-name = last-name]'))
END
GO

CREATE TABLE docs (pk INT PRIMARY KEY,
xCol XML not null
CONSTRAINT CK_name CHECK (udf_Check_Names(xCol) = 0))
GO

텍스트 인코딩

SQL Server 2005는 XML 데이터를 유니코드(UTF-16)로 저장합니다. 또한 서버에서 검색된 XML 데이터는 UTF-16 인코딩으로 제공됩니다. 다른 인코딩을 원할 경우 데이터를 검색한 후에 캐스팅을 통해 또는 중간 계층에서 필요한 변환을 수행해야 합니다. 예를 들어, XML 데이터를 서버에서 varchar 형식으로 캐스팅할 수 있는데 이 경우에 데이터베이스 엔진은 varchar의 데이터 정렬에서 결정된 인코딩으로 XML을 직렬화합니다.

XML 데이터 저장

XML 열, 매개 변수 또는 변수에 대한 XML 값을 다음과 같은 여러 방법으로 제공할 수 있습니다.

  • XML 데이터 형식으로 암시적으로 변환되는 문자 또는 이진 SQL 형식으로

  • 파일 콘텐츠로

  • XML 데이터 형식 인스턴스를 생성하는 TYPE 지시문이 포함된 XML 게시 메커니즘 FOR XML의 출력으로
제공된 값은 형식이 올바른지 검사되며 XML 문서와 XML 단편을 모두 저장하는 것이 허용됩니다. 형식이 올바른지 않은 경우 해당 오류 메시지와 함께 데이터는 거부됩니다.

형식있는 XML의 경우 XML 열을 형식화하는 XML 스키마 컬렉션에 등록된 XML 스키마를 따르는지 여부를 제공된 값에서 검사합니다. 이 유효성 검사에 실패할 경우 XML 인스턴스는 거부됩니다. 또한 CONTENT에서 XML 문서와 콘텐츠를 모두 제공하도록 허용하는 것과 달리 형식있는 XML의 DOCUMENT 플래그에서는 허용되는 값이 XML 문서로 제한됩니다.

예제: 형식없는 XML 열에 데이터 삽입

다음 문은 정수 열 pk에 대한 값 1과 XML 열에 대한 <book> 인스턴스와 함께 테이블 docs에 새 행을 삽입합니다. 문자열로 제공되는 <book> 데이터는 XML 데이터 형식으로 암시적으로 변환되며 삽입 도중에 형식이 올바른지 검사됩니다.

INSERT INTO docs VALUES (1,
'<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>')
INSERT INTO docs VALUES (2,
'<doc id="123">
<sections>
<section num="1"><title>XML Schema</title></section>
<section num="3"><title>Benefits</title></section>
<section num="4"><title>Features</title></section>
</sections>
</doc>')

예제: 파일에서 형식없는 XML 열에 데이터 삽입

아래 나온 INSERT 문은 OPENROWSET을 사용하여 C:\temp\xmlfile.xml 파일의 내용을 BLOB로 읽습니다. 기본 키에 대한 값 10과 XML 열 xCol에 대한 BLOB와 함께 테이블 docs에 새 행식이 올바른지 검사됩니다.

INSERT INTO docs
SELECT 10, xCol
FROM (SELECT * FROM OPENROWSET
(BULK 'C:\temp\xmlfile.xml',
SINGLE_BLOB) AS xCol) AS R(xCol)

예제: 형식있는 XML 열에 데이터 삽입

형식있는 XML 열에서는 형식화하는 데 사용되는 XML 스키마의 대상 네임스페이스(빈 네임스페이스 가능)를 지정하기 위해 XML 인스턴스 데이터가 필요합니다. 이를 위해서 아래 예제에서는 네임스페이스 선언 xmlns=http://myDVD가 사용됩니다.

INSERT XmlCatalog VALUES(2,
'<xml version="1.0">
<dvdstore xmlns="http://myDVD">
<dvd genre="Comedy" releasedate="2003">
<title>My Big Fat Greek Wedding</title>
<price>19.99</price>
</dvd>
</dvdstore>')

예제: TYPE 지시문과 함께 FOR XML을 사용하여 생성한 XML 데이터 저장

결과를 XML 데이터 형식 인스턴스로 생성하기 위해 TYPE 지시문을 사용하도록 FOR XML이 향상되었습니다. 결과 XML을 XML 열, 변수 또는 매개 변수에 할당할 수 있습니다. 다음 문에서 FOR XML TYPE을 사용하여 생성된 XML 인스턴스는 XML 데이터 형식 변수 @xVar에 할당됩니다. XML 데이터 형식 메서드를 사용하여 변수를 쿼리할 수 있습니다.

DECLARE @xVar XML
SET @xVar = (SELECT * FROM docs FOR XML AUTO,TYPE)

저장소 표현

XML 데이터 형식 인스턴스는 스트리밍 가능하며 효율적 구문 분석을 위해 최적화된 내부 이진 표현에 저장됩니다. 태그는 정수 값에 매핑되며 매핑된 값은 내부 표현에 저장됩니다. 이 과정에서 데이터가 일부 압축되기도 합니다.

형식없는 XML의 경우 노드 값은 유니코드(UTF-16) 문자열로 저장되므로 작업을 수행하려면 런타임 형식 변환이 필요합니다. 예를 들어, 조건자 /book/price > 9.99를 평가하려면 책 가격의 값은 10진수로 변환되어야 합니다. 반면, 형식있는 XML의 경우 값은 XML 스키마에 지정된 형식으로 인코딩됩니다. 따라서 데이터 구문 분석이 훨씬 더 효율적으로 수행되며 런타임 변환이 방지됩니다.

저장된 이진 형식은 각 XML 인스턴스마다 2GB로 제한되며 이것은 대부분의 XML 데이터를 수용할 수 있는 크기입니다. 또한 XML 계층의 깊이는 128개 수준으로 제한됩니다.

XML 데이터의 InfoSet (영문) 콘텐츠는 유지됩니다. 중요하지 않은 공백, 특성 순서, 네임스페이스 접두사, XML 선언 등과 같은 정보가 유지되지 않기 때문에 텍스트 XML과 다를 수 있습니다.

데이터 모델링 고려 사항

일반적으로 데이터 모델링에는 관계형 및 XML 데이터 형식 열의 조합이 적합합니다. XML 데이터의 일부 값은 관계형 열에 저장될 수 있으며 나머지 또는 전체 XML 값은 XML 열에 저장될 수 있습니다. 이렇게 하면 성능과 잠금 특성이 향상될 수 있습니다.

XML 데이터 내의 값은 동일한 테이블의 싱글톤(singleton) 값(즉, 단일 값 속성)에 대해 계산된 열로 승격될 수 있습니다. 다중 값 속성은 속성에 대한 별개의 테이블이 필요하며 이러한 테이블은 트리거를 사용하여 채우고 유지 관리해야 합니다. 또한 속성 테이블에 대해 쿼리를 직접 작성해야 합니다.

XML 열에 저장된 XML 데이터의 입도(granularity)는 잠금 및 업데이트 특성에 중요합니다. SQL Server는 XML 및 비 XML 데이터 모두에 대해 동일한 잠금 메커니즘을 사용합니다. 입도(granularity)가 클 경우 업데이트를 위해 큰 XML 인스턴스를 잠그면 다수의 사용자가 있는 상황에서 처리 속도가 저하됩니다. 반대로 너무 심하게 분해된 경우에는 개체 캡슐화가 손실되고 리어셈블리 비용이 발생합니다.

XML 데이터 쿼리 및 수정

XML 열에 저장된 XML 인스턴스를 쿼리하려면 열의 이진 XML 데이터를 구문 분석하는 것이 필요합니다. 이진 XML을 구문 분석하는 것은 텍스트 형식의 XML 데이터를 구문 분석하는 것보다 훨씬 빠릅니다. XML 인덱싱은 재분석을 방지하며 "XML 데이터 인덱싱" 절에 설명되어 있습니다.

XML 데이터 형식에 대한 메서드

필요에 따라 전체 XML 값을 검색하거나 XML 인스턴스의 일부를 검색할 수 있습니다. XQuery 식을 인수로 가지는 네 개의 XML 데이터 형식 메서드인 query(), value(), exist() 및 nodes()를 사용하여 이 작업을 수행할 수 있습니다. 또 다른 메서드인 modify()에서는 XML 데이터 수정 문을 입력으로 사용하여 XML 데이터를 수정할 수 있습니다.

query() 메서드는 XML 인스턴스의 일부를 추출하는 데 사용됩니다. XQuery 식은 XML 노드 목록으로 평가됩니다. 이러한 각 노드에서 시작하는 하위 트리는 문서 순서로 반환됩니다. 결과 형식은 형식없는 XML입니다.

value() 메서드는 XML 인스턴스에서 스칼라 값을 추출합니다. 이 메서드는 XQuery 식이 평가되는 노드의 값을 반환합니다. 이 값은 value() 메서드의 두 번째 인수로 지정된 T-SQL 형식으로 변환됩니다.

exist() 메서드는 XML 인스턴스에 대한 실존적 검사를 수행하는 데 사용됩니다. 이 메서드는 XQuery 식이 null이 아닌 노드 목록으로 평가될 경우 1을 반환하고 그렇지 않을 경우 0을 반환합니다.

nodes() 메서드는 특수한 XML 데이터 형식의 인스턴스를 생성하며 각 인스턴스는 XQuery 식이 평가되는 다른 노드로 설정된 컨텍스트를 가집니다. 특수한 XML 데이터 형식은 query(), value(), nodes() 및 exist() 메서드를 지원하며 count(*) 집계와 NULL 검사에 사용될 수 있습니다. 다른 용도로 사용하면 오류가 발생합니다.

modify() 메서드는 XML 인스턴스의 일부를 수정하는 데 사용됩니다. 예를 들어, 하위 트리를 추가 또는 삭제하거나 책 가격과 같은 스칼라 값을 9.99에서 39.99로 바꿀 수 있습니다.

예제: query() 메서드 사용

id가 123인 <doc> 요소 아래의 임의 위치에서 <section> 요소를 추출하는 다음 쿼리가 테이블 docs의 XML 열 xCol에 있습니다. 또한 이 쿼리는 정수 기본 키 열에서 값을 검색합니다. SELECT 목록의 query() 메서드는 일련의 <section> 요소를 생성하는 테이블의 각 행에 대해 평가되며 이러한 요소는 해당 하위 트리와 함께 문서 순서로 검색됩니다. id가 123인 <doc> 요소가 없거나 <section> 요소가 없는 각 XML 인스턴스는 결과를 반환하지 않습니다. 즉, 이 경우 query() 메서드의 반환 값은 빈 XML입니다.

SELECT pk, xCol.query('/doc[@id = 123]//section')
FROM docs

빈 XML 값은 외부 SELECT 문에서 필터링할 수 있습니다. 또는 다음 예제에 나온 것처럼 exist() 메서드를 사용할 수 있습니다.

예제: exist() 메서드 사 있는 query() 및 exist() 메서드를 포함합니다. exist() 메서드는 값이 123인 id라고 부르는 특성을 가진 최상위 <doc> 요소가 존재하는지 검사하는 경로 식 /doc[@id = 123]을 평가합니다. 이러한 각 행에 대해 SELECT 절의 query() 메서드가 평가됩니다. 이 예제에서 query() 메서드는 <doc> 요소 아래의 임의 위치에 일련의 <section> 요소를 생성합니다. exist() 메서드에서 0을 반환하는 모든 행은 건너뜁니다.

SELECT xCol.query('/doc[@id = 123]//section')
FROM docs
WHERE xCol.exist ('/doc[@id = 123]') = 1

예제: value() 메서드 사용

다음 쿼리는 value() 메서드를 사용하여 문서의 세 번째 섹션 제목을 유니코드 문자열로 추출합니다. 결과의 SQL 형식 nvarchar(max)는 value() 메서드의 두 번째 인수로 지정됩니다. XQuery 함수 data()는 <title> 노드에서 스칼라 값을 추출합니다.

SELECT xCol.value(
'data((/doc//section[@num = 3]/title)[1])',
'nvarchar(max)')
FROM docs

예제: XML 데이터 형식 메서드와 함께 GROUP BY 사용

XML 데이터 형식 메서드는 T-SQL GROUP BY 절에서 허용되지 않습니다. 그러나 하위 쿼리의 XML 열에서 값을 추출하고 그룹 열의 별칭을 지정한 후에 GROUP BY 절에서 별칭을 사용할 수 있습니다. 다음 쿼리는 이름이 같은 저자가 출간한 책 개수를 계산하여 이 작업이 수행되는 방법을 보여 줍니다.

SELECT Fname, count(Fname)
FROM
(SELECT nref.value('(author/first-name)[1]', 'nvarchar(max)') Fname
FROM docs CROSS APPLY xCol.nodes('/book') T(nref)
WHERE nref.exist ('author/first-name') = 1) Result
GROUP BY FName
ORDER BY FName

예제: sqlcmd 실헹

XQuery 및 XML 데이터 수정 문을 실행하려면 연결 옵션 QUOTED_IDENTIFIER가 ON이어야 합니다. SQLCMD에서 이 옵션의 기본값은 OFF이므로 -I 스위치를 사용하여 ON으로 변경해야 합니다.

sqlcmd E I d <database> -Q "SELECT xCol.query('//author') FROM docs"

예제: cast() 및 value() 메서드 동작의 차이

query() 메서드는 문자열 형식으로 변환될 때 엔터티화된 특수한 XML 문자를 갖는 XML 데이터 형식 인스턴스를 반환합니다. 반면, value() 메서드는 특수 문자를 엔터티화하지 않은 SQL 형식 값을 반환합니다. 이러한 차이는 이벤트 알림에서 분명하게 나타납니다. 아래의 첫 번째 쿼리는 엔터티화된 캐리지 리턴을 포함할 수 있습니다.

SELECT EVENTDATA().value('
(/EVENT_INSTANCE/TSQLCommand/CommandText/text())[1]','nvarchar(max)')

그러나 다음 두 번째 쿼리는 포함되지 않습니다.

SELECT CAST (EVENTDATA().query('
/EVENT_INSTANCE/TSQLCommand/CommandText/text()') AS nvarchar(max))

XQuery 언어

파일 시스템, 웹 서비스 또는 구성 파일에 저장된 Office 문서의 수많은 XML 소스가 존재합니다. 실제로 XML 형식이나 가상 XML 문서로 생성되는 데이터가 점차 증가하고 있습니다. 이러한 데이터 증가에 대응하기 위해서 강력한 쿼리 언어인 XQuery가 고안되었습니다. http://www.w3.org/TR/xquery (영문) 의 XQuery 언어 사양에는 다음과 같이 XQuery가 설명되어 있습니다.


XML 구조를 지능적으로 사용하는 쿼리 언어는 XML에 실제로 저장되었는지 아니면 미들웨어를 통해 XML로 볼 수 있는지 여부에 상관 없이 모든 종류의 데이터에서 쿼리를 표현할 수 있습니다. 이 사양에서 설명하는 XQuery라는 쿼리 언어는 많은 유형의 XML 데이터 소스에서 광범위하게 적용할 수 있도록 설계되었습니다.


XQuery는 W3C XML Query Working Group의 XML 쿼리 1.0 요구 사항에서 식별된 요구 사항과 XML 쿼리 사용 사례에 제시된 사례를 충족하도록 설계되었습니다. 또한 XQuery에서는 쿼리가 간결하고 이해하기 쉽도록 되어 있습니다. XQuery는 데이터베이스 및 문서를 비롯한 광범위한 XML 정보 소스를 쿼리할 수 있는 유연성을 제공합니다.


이외에도 "XQuery 언어와 XMl의 관계는 SQL 언어와 관계형 데이터베이스의 관계와 같습니다."라는 문장으로 XQuery를 요약할 수 있습니다.

T-SQL에 포함된 XQuery의 하위 집합 (http://www.w3.org/TR/xquery/ (영문))은 XML 데이터 형식을 쿼리하기 위해 지원되는 언어입니다. Microsoft를 비롯한 모든 주요 데이터베이스 공급업체가 참여하는 W3C(Worldwide Web Consortium)에서 이 언어를 개발하고 있습니다(최종 승인 단계가 남아 있음). 현재의 구현은 2004년 7월에 발표된 XQuery 초안에 기반을 두고 있습니다.

XQuery에는 XPath 2.0이 탐색 언어로 포함되어 있습니다. SQL Server 2005에서 구현된 XQuery는 노드 반복(for), 노드 검사(where), 값 반환(return) 및 정렬(order by)을 위한 구문을 제공합니다. 또한 쿼리 도중에 데이터의 형태를 변경하기 위한 요소 생성을 제공합니다.

이외에도 SQL Server 2005에서는 XML 데이터 형식의 데이터 수정을 위한 언어 구문(DML)이 제공됩니다(자세한 내용은 아래의 데이터 수정 절 참조). 다음 예제는 XML 데이터 형식에서 XQuery를 사용하는 방법을 보여 줍니다.

예제: XQuery의 풍부한 언어 구문 사용

아래 쿼리는 함께 사용되는 여러 XQuery 언어 구문을 보여 줍니다. 이 쿼리는 id가 123인 문서에서 섹션 번호가 3 이상인 섹션의 제목을 새 태그 <topic>에 래핑된 상태로 반환합니다.

SELECT pk, xCol.query('
for $s in /doc[@id = 123]//section
where $s/@num >= 3
return <topic>{data($s/title)}</topic>')
FROM docs

"for"는 id가 123인 <doc> 요소 아래의 모든 <section> 요소에서 반복되고 이러한 각 <section>을 $s 변수에 바인딩합니다. "where"는 섹션 번호(<section> 요소의 @num 특성)가 3 이상인지 확인합니다. 쿼리는 <topic>이라는 생성된 요소에 래핑된 섹션 <title>의 값을 문서 순서대로 반환합니다.

쿼리 컴파일 및 실행

SQL 문은 SQL 파서에 의해 구문 분석됩니다. XQuery 식이 있으면 XQuery 컴파일러로 이동하고 XQuery 컴파일러가 XQuery 식을 컴파일합니다. 이러한 과정에서 전체 쿼리에 대한 하나의 쿼리 트리가 생성됩니다.

전체 쿼리 트리에 대해 쿼리 최적화가 수행되며 비용 기반 예측에 기반을 두고 선택된 실제 쿼리 계획이 생성됩니다. 실행 계획 출력에는 대개 관계형 연산자와 몇 가지 새로운 연산자(예: XML 처리를 위한 UDX)가 표시됩니다.

관계형 프레임워크의 다른 부분과 마찬가지로 쿼리 실행은 튜플 지향적입니다. WHERE 절은 테이블 docs의 각 행에서 평가되며 런타임에 XML BLOB을 구문 분석하여 XML 데이터 형식 메서드를 평가하는 것이 여기에 포함됩니다. 조건을 충족할 경우 행이 잠기고 행에서 SELECT 절이 평가됩니다. 결과는 query() 메서드의 XML 데이터 형식으로 생성되며 value() 메서드의 지정된 대상 형식으로 변환됩니다.

반면, 행에서 WHERE 절의 조건을 충족하지 않을 경우 해당 행을 건너뛰고 다음 행이 실행됩니다.

XML 데이터 수정

SQL Server 2005는 데이터 수정을 위한 구문을 확장된 XQuery의 형태로 제공합니다. 하위 트리를 지정된 노드의 앞이나 뒤에 삽입하거나 맨 왼쪽 또는 맨 오른쪽 자식으로 삽입할 수 있습니다. 또한 하위 트리를 부모 노드에 삽입할 수 있으며 이 경우에 하위 트리는 부모의 맨 오른쪽 자식이 됩니다. 특성, 요소 및 텍스트 노드 삽입이 모두 지원됩니다.

또한 하위 트리를 삭제할 수 있습니다. 이 경우 전체 하위 트리가 XML 인스턴스에서 제거됩니다.

스칼라 값을 새 스칼라 값으로 바꿀 수 있습니다.

예제: 하위 트리를 XML 인스턴스에 삽입

다음 예제는 modify() 메서드를 사용하여 새 <section> 요소를 번호가 1인 <section> 요소의 오른쪽에 삽입하는 방법을 보여 줍니다.

UPDATE docs SET xCol.modify('
insert
<section num="2">
<title>Background</title>
</section>
after (/doc/section[@num=1])[1]')

예제: 책 가격을 $49.99로 업데이트

다음 업데이트 문은 ISBN이 1-8610-0311-0인 책의 <price>를 $49.99로 바꿉니다. XML 인스턴스는 XML 데이터 수정 문의 네임스페이스 선언인 XML 스키마 http://myBooks로 형식화됩니다.

UPDATE XmlCatalog
SET Document.modify ('
declare namespace bk = "http://myBooks";
replace value of (/bk:bookstore/bk:book
[@ISBN="1-861003-11-0"]/bk:price)[1] with 49.99')

형식 검사 및 정적 오류

XQuery에서는 형식 검사가 수행됩니다. 컴파일 단계에서 XQuery 식과 데이터 수정 문의 정적 형식 정확성이 검사되며 형식있는 XML의 경우 형식 유추를 위해 XML 스키마가 사용됩니다. 형식 안전 위반으로 런타임에 식이 실패할 경우 정적 형식 오류가 발생합니다. 정적 오류의 예로는 문자열을 정수에 추가하거나 단일 값이 필요한 작업에서 값 시퀀스를 수신하거나 존재하지 않는 노드에서 형식있는 데이터를 쿼리하는 경우 등이 있습니다. 형식 불일치로 인한 정적 오류를 해결하는 방법은 적절한 형식으로 명시적 캐스팅을 수행하는 것입니다. 그러면 XQuery 런타임 오류가 빈 시퀀스로 변환됩니다.

런타임에 싱글톤(singleton)이 보장되는지 여부를 컴파일러에서 확인할 수 없는 경우 싱글톤(singleton)이 필요한 위치 단계, 함수 매개 변수 및 연산자(예: eq)는 오류를 반환합니다. 형식없는 데이터의 경우 문제가 자주 발생합니다. 예를 들어, 특성 조회에는 싱글톤(singleton) 부모 요소가 필요하며 단일 부모 노드를 선택하는 서수가 적합합니다.

예제: value() 메서드의 형식 검사

형식없는 XML 열에 대한 아래 쿼리에서는 싱글톤(singleton) 노드가 첫 번째 인수로 value() 메서드에 사용되기 때문에 //author/last-name에 서수 지정이 필요합니다. 이 값이 없을 경우 컴파일러는 런타임에 <last-name> 노드가 하나만 발생하는지 여부를 확인할 수 없습니다.

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

다음 예제에 나온 것처럼 node()-value() 조합을 평가하여 특성 값을 추출하는 경우에는 서수 지정이 필요하지 않을 수 있습니다.

예제: 알려진 싱글톤(singleton)

아래 나온 nodes() 메서드는 각 <book> 요소에 대한 별개의 행을 생성합니다. <book> 노드에서 평가되는 value() 메서드는 특성이 되는 싱글톤(singleton)인 @genre의 값을 추출합니다.

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

도메인 간의 데이터 바인딩

관계형 및 XML 데이터 형식 열의 조합에 데이터가 상주할 경우 관계형 및 XML 데이터 처리를 결합하는 쿼리를 작성하는 것이 필요할 수 있습니다. TYPE 지시문과 함께 FOR XML을 사용하여 관계형 및 XML 열의 데이터를 XML 데이터 형식 인스턴스로 변환하고 XQuery를 사용하여 쿼리할 수 있습니다. 반대로 아래의 "XML 데이터에서 행 집합 생성" 절에 나온 것처럼 XML 값에서 행 집합을 생성하고 T-SQL을 사용하여 쿼리할 수 있습니다.

교차 도메인 쿼리를 작성하는 데 쉽고 효율적인 방법은 XQuery 또는 XML 데이터 수정 식 내에서 SQL 변수나 열의 값을 사용하는 것입니다.


sql:variable()을 사용하여 XQuery 또는 XML DML 식에서 SQL 변수 값을 적용합니다.


sql:column()을 사용하여 XQuery 또는 XML DML 컨텍스트에서 관계형 열의 값을 사용합니다.

이 접근 방법을 사용하면 아래 예제에 나온 것처럼 응용 프로그램에서 쿼리를 매개 변수화할 수 있습니다. Sql:column()은 비슷한 방식으로 사용되지만 더 많은 이점을 제공합니다. 비용 기반 쿼리 최적화 프로그램에서 결정하는 것처럼 효율성을 확보하기 위해 열에서 인덱스를 사용할 수 있습니다. 또한 계산된 열을 사용할 수도 있습니다.

XML 및 사용자 정의 형식은 sql:variable() 및 sql:column()에서 사용하는 것이 허용되지 않습니다.

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

이 쿼리에서는 SQL 변수 @isbn을 사용하여 <book> 요소의 ISBN이 전달됩니다. 상수를 사용하는 대신에 sql:variable()은 ISBN 값을 제공하며 쿼리를 사용하여 단순히 ISBN이 0-7356-1588-2인 경우가 아니라 모든 ISBN을 검색할 수 있습니다.

DECLARE @isbn varchar(20)
SET @isbn = '0-7356-1588-2'
SELECT xCol
FROM/ ??P>

XML 데이터에서 행 집합 생성

사용자 지정 속성 관리 및 데이터 교환 시나리오에서 대개 응용 프로그램은 XML 데이터의 일부분을 행 집합에 매핑합니다. 예를 들어, 입력 매개 변수 테이블을 저장 프로시저나 함수에 전달하기 위해 응용 프로그램은 데이터를 XML로 변환하고 XML 데이터 형식 매개 변수로 전달합니다. 저장 프로시저 또는 함수 내에서 행 집합은 XML 매개 변수에서 다시 생성됩니다.

SQL Server 2000은 이 목적을 위해 OpenXml()을 제공합니다. 이 메서드는 행 집합에 대한 관계형 스키마를 지정하고 XML 인스턴스 내의 값이 행 집합의 열에 매핑되는 방법을 지정하여 XML 인스턴스에서 행 집합을 생성합니다.

또는 nodes() 메서드를 사용하여 XML 인스턴스 내에 노드 컨텍스트를 생성할 수 있으며 value(), query(), exist() 및 nodes() 메서드에서 노드 컨텍스트를 사용하여 원하는 행 집합을 생성할 수 있습니다. nodes() 메서드는 제공된 XQuery 식을 XML 열의 각 XML 인스턴스에서 평가하고 XML 인덱스를 효과적으로 사용합니다. 다음 예제는 행 집합 생성을 위해 nodes() 메서드를 사용하는 방법을 보여 줍니다.

예제: XML 인스턴스에서 속성 추출

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

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

이 예제에서 nodes('//author')는 각 XML 인스턴스의 <author> 요소에 대한 참조 행 집합을 생성합니다. 저자의 이름과 성은 이러한 참조를 기준으로 value() 메서드를 평가하는 방법을 통해 가져옵니다. 다음 절에서 설명된 것처럼 우수한 성능을 위해 XML 열을 인덱싱해야 합니다.

예제: XML 변수에서 속성 추출

XML 변수나 매개 변수에서 속성을 추출할 경우 위 쿼리의 CROSS APPLY 연산자가 필요하지 않습니다. 다음 예제에서는 <book> 인스턴스가 할당되는 XML 변수 @xVar를 고려하고 저자의 <first-name> 및 <last-name>을 검색합니다.

DECLARE @xVar XML
SET @xVar =
'<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>'

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

XML 데이터 인덱싱

XML 데이터는 내부 이진 형식으로 저장되며 최대 저장 크기는 2GB가 될 수 있습니다. 각 쿼리는 테이블의 각 행에서 XML BLOB을 런타임에 한 번 이상 구문 분석합니다. 이로 인해서 쿼리 처리 속도가 느려집니다. 데이터 수정 도중에 XML 인덱스 유지 관리를 위한 비용을 고려해야 하지만 쿼리가 작업 부하에서 일반적으로 수행되는 경우에는 XML 열을 인덱싱하는 것이 유리합니다.

형식 있는/없는 XML 열에서 새로운 DDL 문을 사용하여 XML 인덱스를 만듭니다. 이렇게 하면 열의 모든 XML 인스턴스에 대해 B+ 트리가 만들어집니다. XML 열의 첫 번째 인덱스는 "기본 XML 인덱스"입니다. 다음 절에서 설명된 것처럼 이 인덱스를 사용하여 XML 열에서 세 가지 유형의 보조 XML 인덱스가 지원되며 공통된 쿼리 클래스의 속도가 향상됩니다.

기본 XML 인덱스

기본 XML 인덱스는 기본 테이블(즉, XML 열이 정의된 테이블)의 기본 키에서 클러스터된 인덱스가 필요합니다. 이 인덱스는 XML 노드의 Infoset 항목 하위 집합에서 B+ 트리를 만듭니다. B+ 트리의 열은 요소 및 속성 이름, 노드 값, 노드 유형 등과 같은 태그를 나타냅니다. 다른 열은 경로 식의 효율적인 평가를 위해서 XML 데이터의 문서 순서와 구조를 캡처하고 XML 인스턴스 루트에서 각 노드까지의 경로를 캡처합니다. 인덱스 행을 기본 테이블 행과 상관시키기 위해 기본 테