KR101086567B1

KR101086567B1 - 데이터베이스 저장소 내의 한 객체로서 캡슐화된 ｘｍｌ데이터를 저장 및 검색하기 위한 시스템 및 방법

Info

Publication number: KR101086567B1
Application number: KR1020057010612A
Authority: KR
Inventors: 샨카르 팔; 라마찬드란 반카테쉬; 호세 에이. 블라켈리; 데니스 와이. 알투도브; 이스트반 크세리; 치아-선 첸; 알라젤 애치슨
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-24
Filing date: 2004-07-29
Publication date: 2011-11-23
Also published as: WO2005046103A2; WO2005046103A3; EP1627508A4; EP1627508A2; CN101410830A; KR20060112187A; JP2007519078A; US20050091231A1

Abstract

데이터베이스 저장소 내의 사용자 정의 타입(UDT)의 단일 인스턴스 내의 구조적, 세미-구조적 및 비구조적 데이터 모두를 모델링하기 위한 시스템 및 방법이 제공된다. 특히, XML 데이터 모델은 UDT의 필드에 확장된다. 결과적으로, 문서 순서 및 문서 구조와 같은 XML 데이터 모델의 속성은 UDT의 인스턴스 내에 보존될 수 있다. 또한, 객체 동작을 나타내는 코드(즉, 관리되는 코드의 객체 상에서 호출될 수 있는 메소드)가 UDT에 추가되어, XML 필드 뿐만 아니라 UDT의 비-XML 필드에 대해 동작할 수 있다. 이것은 XML 데이터에 비지니스 논리를 추가하기 위한 프레임워크를 가능하게 한다. XML 데이터의 컨텐츠 모델은 UDT의 XML 필드에 연계된 XML 스키마 문서를 이용하여 선택적으로 설명될 수 있다.

사용자 정의 타입, 인스턴스, XML

Description

데이터베이스 저장소 내의 한 객체로서 캡슐화된 ＸＭＬ 데이터를 저장 및 검색하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR STORING AND RETRIEVING XML DATA ENCAPSULATED AS AN OBJECT IN A DATABASE STORE}

<관련 출원에 대한 상호참조>

본 출원은 2003년 10월 24일자 미국 출원번호 제10/693,158호에 대한 우선권을 주장하며, 그 기재는 여기에서 온전히 참조로서 통합된다.

<저작권 공지 및 허가>

본 특허 문헌의 명세서의 일부는 저작권 보호를 받는 자료를 포함한다. 본 저작권 소유자는 본 특허 문헌 또는 본 특허 명세서가 특허청의 포대 또는 기록에 나타나 있으므로 임의의 자에 의한 이들의 팩시밀리 재현에는 이의를 제기하지 않지만, 그 밖의 모든 사항에 대해서는 어떤 경우에라도 모든 저작권을 보유한다. 다음의 공지는 본 문서에 적용된다: Copyright ⓒ 2003, Microsoft Corp.

<본 발명의 분야>

본 발명은 컴퓨터 시스템에서의 데이터 저장에 관한 것으로서, 특히, 사용자 정의 타입의 필드로서의 데이터베이스 저장소 내의 XML 데이터를 저장 및 검색하기 위한 시스템 및 방법에 관한 것이다.

마이크로소프트(Microsoft) SQL SERVER는 다양한 관리 개발 도구, 강력한 추출(Extraction), 변환(Transformation), 로딩(Loading)(ETL) 도구, 사무 지능 및 분석 서비스, 및 다른 기능 등을 제공하는 종합적인 데이터베이스 관리 플랫폼이다. 최근에 SQL SERVER에 대해 두개의 개선이 구현되었다. 첫째로, 마이크로소프트 윈도우즈 .NET 프레임워크(Framework)의 공통 언어 런타임(Common Language Runtime, CLR)이 SQL SERVER 데이터베이스에 통합되었고, 두 번째로는, 사용자 정의 타입(UDT)으로 불리는 새로운 객체를 현재 CLR 환경에서 관리되는 코드로 생성할 수 있고 데이터베이스 저장소에 보존할 수 있다.

CLR은 마이크로소프트 .NET 프레임워크의 핵심이며, 모든 .NET 코드의 실행 환경을 제공한다. 따라서, CLR 안에서 실행되는 코드는 "관리되는 코드(managed code)"라 일컫는다. CLR은 JIT(just-in-time) 컴파일러, 메모리 배정과 관리, 타입 안전성의 강화, 예외 처리, 스레드(thread) 관리와 보안을 포함하여 프로그램 실행에 필요한 다양한 기능과 서비스를 제공한다. 그리고 CLR은 SQL SERVER에 의해 .NET 루틴의 첫번째 호출 시 로드된다.

SQL SERVER의 이전 버전에서, 데이터베이스 프로그래머는 Transact-SQL(T-SQL)를 사용해서 서버측 코드를 작성할 때 제한을 받았다. Transact-SQL은 국제 표준 기구(International Standard Organization, ISO)와 미국 표준 협회(American National Standards Institute, ANSI)에서 정의한 사용자 정의 쿼리 언어의 확장된 언어이다. Transact-SQL를 사용해서, 데이터베이스 개발자는 데이터베이스에 저장된 데이터를 삽입, 검색, 수정 및 삭제할 뿐만 아니라 데이터베이스 및 테이블을 생성, 수정 및 삭제할 수 있다. Transact-SQL은 특히 구조적 데이터의 직접 접근 및 조작을 위해 설계되었다. Transact-SQL은 데이터의 접근 및 관리에서 탁월한 반면, Visual Basic .NET 및 C#처럼 완전히 성숙된 프로그래밍 언어가 아니다. 예로, Transact-SQL은 루프(loop), 비트 시프팅(bit shifting) 또는 클래스(class) 각각에 대해서 배열(array), 수집(collection)을 지원하지 않는다.

CLR이 통합된 SQL SERVER 데이터베이스로, 데이터베이스 개발자는 Transact-SQL 단독으로 불가능하거나 달성하기 힘들었던 태스크들을 지금 이행할 수 있다. Visual Basic .NET 과 C#은 둘다 배열, 사용자 정의 예외 처리, 및 수집에 대해 충분한 지원을 제공하는 최신 프로그래밍 언어이다. 개발자는 CLR 통합의 지레 작용으로 Visual Basic .NET 및 C#과 같은 언어를 사용하는 보다 복잡한 논리를 갖춘 계산 태스크에 더욱 적합한 코드를 작성할 수 있다.

CLR 통합 이외에, SQL SERVER는 사용자 정의 타입(UDT), 즉 개발자로 하여금 데이터베이스의 스칼라(scalar) 타입 시스템을 확장할 수 있는 새로운 메커니즘에 대한 지원도 추가했다. UDT는 응용 프로그램 아키텍처 관점에서 두개의 중요한 편의를 제공한다: 내부 상태와 외부 동작(behavior)사이에 강력한 캡슐화(encapsulation)를 (클라이언트와 서버 양쪽에) 제공하고, 다른 관련된 서버 특징과의 두터운 통합을 제공한다. 일단 UDT가 정의되면, SQL SERVER에서 칼럼 정의, 변수, 매개 변수, 함수의 결과, 커서, 트리거, 및 복제를 포함하여 시스템 타입을 사용할 수 있는 모든 콘텍스트(context)에서 사용할 수 있다.

데이터베이스 서버에서 UDT를 정의하는 프로세스는 다음과 같이 작성된다:

a) UDT 생성 규칙을 준수하는 관리되는 코드로 클래스를 생성한다;

b) CREATE ASSEMBLY 구문을 사용해서 서버 데이터베이스에 UDT를 포함한

ASSEMBLY를 로딩한다; 및

c) 관리되는 코드 UDT를 노출하는 CREATE TYPE 구문을 사용해서 데이터베이스에

타입을 생성한다.

이 시점에서, UDT는 테이블 정의에 사용될 수 있다.

관리되는 코드로 UDT 정의가 생성되면, 타입은 다음 조건들을 지켜야 한다:

a) Serializable로 표기되어야 한다;

b) SqlUserDefinedTypeAttribute로 장식되어야 한다;

c) IsNullable 인터페이스 구현으로 NULL 지원이 되어야 한다;

d) 인수를 취하지 않는 공용 생성자를 갖추어야 한다; 및

e) 아래의 메소드를 구현하여 문자열로 전환 및 문자열에서 전환이 지원

되어야 한다:

1. Public String ToString(); 및

2. Public Shared <type> Parse (SqlString s).

2003년 10월 23일자의 "데이터베이스 저장소의 객체 보존을 위한 시스템과 방법(System And Method For Object Persistence In A Database Store)"으로 명명되어, 공동으로 양도되어 공동 계류중인 특허 출원 일련 번호 인 특허(대리인 번호: MSFT-2852/306819.1)는, 참고로 본 명세서에 전부 편입하였는데, UDT의 CLR 클래스 정의의 필드와 동작이 데이터베이스 저장소의 UDT 인스턴스에 대한 배치 구조를 설명하는 저장소 속성으로 주석된 UDT의 다른 특징을 설명한다. 특히, UDT를 정의하는 CLR 클래스의 각 필드는 크기, 정확성, 비율 등과 같은 타입의 저장 요소를 조절하는 저장 속성으로 주석된다. 한 실시예에서, 이러한 것은 커스텀(custom) 저장 속성인 SqlUdtField()로 각 필드를 주석하여 달성한다. 이 속성은 필드를 추가적인 저장 지시(directive)로 주석한다. 이런 지시는 객체가 디스크에 직렬화될 때 실행된다. 게다가, CLR 클래스에 정의된 각 관리되는 동작(managed behavior)(예를 들어, UDT 객체에서 호출되어 필드의 값을 반환하는 메소드)은 그 관리되는 동작의 동등한 구조적 접근 경로를 가리키는 속성으로 주석된다. 한 실시예에서, 이러한 목적에 쓰이는 커스텀 속성은 SqlUdtProperty()이고, 데이터베이스 서버(예로, SQL SERVER)는 이런 커스텀 속성으로 주석된 특성의 구현을 속성 정의의 부분처럼 서술된 필드에 위임하는 것으로 간주한다. 이에 의해, 서버는 서버 상에 인스턴스를 생성하거나 동작을 호출하지 않고서도, 특성에 대한 접근을 구조적으로 최적화할 수 있게 된다.

도 1은 UDT를 정의하는 CLR 클래스의 한 예시적인 코드 리스트이다. 보이는 것처럼, CLR 클래스는 앞에 설명한 것처럼 SqlUdtField()와 SqlUdtProperty() 커스텀 속성으로 주석되었다. 특히, SqlUdtField() 커스텀 속성은 예시적인 UDT 클래스 정의의 각각의 필드를 주석하기 위해 라인 5, 8, 37, 및 49에 첨가되었다. SqlUdtProperty() 커스텀 속성은 클래스의 각각의 관리되는 동작을 주석하기 위해 라인 11과 24에 첨가되었다.

이어서, UDT를 정의하는 CLR 클래스는 동적 링크 라이브러리(dynamic link library, dll)로 컴파일된다. 그리고나서, 컴파일된 클래스를 포함하는 Assembley는 아래의 T-SQL 스크립트 커맨드를 사용해서 생성될 수 있다.

create assembly test

from 'c:\test.dll'

go

아래의 T-SQL 스크립트 커맨드는 서버에 UDT를 생성하는데 사용된다:

create type BaseItem

external name [test]:[BaseItem]

go

일단 UDT가 서버에 생성되면, 테이블의 속성을 UDT 타입으로서 정의하여 테이블(예로, "MyTable")을 아래와 같이 생성할 수 있다:

create table Mytable

(

Item BaseItem,

ItemId as item::ID

)

go

새로운 Item은 아래처럼 테이블에 추가할 수 있다:

declare @i BaseItem

set @i=convert(BaseItem, '')

insert into MyTable values(@i)

go

UDT 표현식(expression)은 SELECT Item.ID, Item.Name FROM MyTable과 같은 쿼리에 사용할 수 있다.

CLR을 SQL SERVER에 통합하고, 관리되는 코드로 된 클래스 정의로부터 UDT를 정의할 수 있게 됨에 따라, 응용 프로그램은 관리되는 코드 클래스로 정의된 타입의 객체를 인스턴스화하고, 그러한 객체를 관계형 데이터베이스 저장소 내에 UDT로서 보존한다. 또한, UDT를 정의하는 클래스는 그 타입의 객체에 대한 특정 동작을 구현하는 메소드를 포함할 수 있다. 따라서, 응용 프로그램은 UDT로 정의된 타입의 객체를 인스턴스화할 수 있고, 그 객체에 동작하는 관리되는 동작을 호출할 수 있다.

UDT로 정의된 클래스의 객체가 CLR에서 인스턴스화되면, 그 객체는 객체 직렬화(serialization)의 프로세스를 통해 데이터베이스 저장소에 보존될 수 있으며, 클래스의 변수 값들은 물리 저장 장치(예, 하드 디스크)에 전이된다. 도 2는 메모리 내의 객체를 디스크 상에서의 객체 보전 형태로 직렬화하는 것을 도시한다. 객체는 도 3에 도시한 전통적인 관계형 데이터베이스 테이블 형태로 데이터베이스 저장소에 보존될 수 있다. 도면에 나타나 있는 바와 같이, 테이블은 서술된 UDT의 칼럼을 포함한다. 서술된 UDT의 보존된 객체의 직렬화 값은 UDT 칼럼의 한 셀(cell)을 차지한다.

도 2를 다시 참조하여, 응용 프로그램이 데이터베이스 저장소에 보존된 UDT 객체의 관리되는 동작(예로, UDT 객체의 필드 값을 반환하는 동작)을 참조하는 술어나 표현식을 포함하는 쿼리를 발생시키면, 보존된 객체는 역 직렬화(de-serialization)(때로는 수화(hydration)라고도 함)되어야 하며, CLR은 객체의 저장된 값을 수신하기 위하여 객체에 대해 메모리를 충분히 배정하여야 한다. 이어서, CLR은 쿼리의 주제인 값을 반환하는 UDT 클래스의 실제 메소드(예, 동작)를 호출해야 한다. 상기에서 인용한 공동 계류중인 출원 번호 (대리인 번호: MSFT-2852/306819.1)에 기재되어 있는 바와 같이, UDT의 CLR 클래스 정의 내의 SqlUdtField()와 SqlUdtProperty() 주석을 데이터베이스 서버가 사용할 수 있어, 객체 수화를 필요로 하지 않고서 특정 UDT 필드의 값에 대한 직접적인 구조적 접근도 허용할 수 있다.

XML(eXtensible Markup Language)은 인간-판독가능한 태그로 데이터를 마크업하기 위해 일반 신택스를 제공하는 문서 및 데이터 표시를 위한 월드 와이드 웹 컨소시엄(W3C) 보증된 표준이다. XML은 고정된 태그 세트를 갖지 않기 때문에, 사용자가 XML 표준을 따르기만 하면 그러한 태그를 정의하게 한다. 데이터는 텍스트 마크업으로 둘러싸인 텍스트 스트링으로서 XML 문서 내에 저장될 수 있다. W3C는 XML 정보 세트(XML 정보세트)라 불리는 명세서에서 XML의 추상 데이터 모델을 성문화하였다. XML 스킴은 또한, XML 포맷 및 컨텐츠에 구조체를 적용하는 데 사용될 수 있다. XML 스키마의 경우에, 문서 내의 XML 데이터에 대한 다이어그램, 플랜 또는 프레임워크가 정의될 수 있다. XML은 문서의 컨텐츠를 쉽게 설명할 수 있는 잘 알려진 포맷이지만, 다른 비-XML 포맷의 데이터가 동일한 데이터베이스에서 바람직할 수 있다. 이것은 고유의 비호환성으로 인해, 잠재적인 쿼리 문제를 발생시킨다. 그러한 비호환성의 예는 관계형 데이터베이스 내의 XML 컨텐츠의 존재이다.

기존 데이터베이스 관리 시스템은 관계형 데이터베이스 저장소 내에 XML 데이터를 저장하기 위한 지원을 제공한다. 예를 들어, 마이크로소프트의 SQL SERVER는 XML 데이터 타입 컬럼, 변수 및 파라미터에 대한 지원을 제공한다. 당신은 하나 이상의 XML 컬럼을 갖는 테이블을 생성하고, XML 컬럼 내에 XML 값을 저장하고, XML 스키마 네임스페이스를 이용하여 XML 컬럼을 타입지정하고, XML 컬럼을 인덱싱하고, XML 값에 쿼리할 수 있다. 그러나, 과거에는 이러한 예에서 관계형 데이터베이스 내에 XML 데이터를 저장하는 것이 가능했지만, 관리되는 코드로 생성되는 사용자 정의 타입의 필드에 XML을 포함시킬 수 있는 것이 바람직할 것이다. 본 발명은 이러한 능력을 제공한다.

<발명의 요약>

본 발명은 사용자 정의 타입(UDT)의 필드 내에 XML 데이터를 저장하기 위한 시스템 및 방법에 관한 것이다. 하나 이상의 UDT 필드는 XML 데이터 타입으로서 정의될 수 있고, UDT도 다른 비-XML 필드를 가질 수 있다. XML 데이터 모델에 부합하는 데이터는 XML 필드 내에 저장될 수 있지만, 비-XML 데이터는 비-XML 필드 내에 저장된다. 따라서, 문서 순서 및 문서 구조와 같은 XML 데이터 모델의 속성은 UDT의 인스턴스 내에서 보존된다. 또한, 객체 동작을 나타내는 코드(즉, 관리되는 코드로 객체에 대해 호출될 수 있는 메소드)가 UDT에 추가되어, XML 필드 뿐 만 아니라 UDT의 비-XML 필드에 대해서도 동작할 수 있다. 이것은 XML 마크업을 갖는 세미-구조화된 데이터에 비지니스 논리를 추가하기 위한 프레임워크를 가능하게 한다. 또한, XML 데이터의 컨텐츠 모델은 UDT의 XML 필드에 연계된 XML 스키마 문서를 이용하여 선택적으로 설명될 수 있다.

본 발명에 따라, XML 필드를 UDT로 도입하기 위해, XML 필드를 적합한 CLR 타입으로서 노출시키는 공통 언어 런타임(CLR) 프로그래밍 모델이 제공된다. 바람직하게, 이것은 SqlXml이라고 불리는 클래스로서 모델링된다. XML 데이터 타입 필드에 대하여, SqlXml 멤버는 SqlUDTField 주석 내에서 "XmlSchemaCollection"이라 불리는 새로운 속성을 허용한다. SqlXml 클래스는 서버에서 XML 데이터 타입으로의 ADO.NET 액세스에 유용하다.

본 발명의 다른 특징 및 장점은 본 발명의 다음의 상세한 설명 및 첨부 도면으로부터 명백해질 수 있다.

상술된 요약 뿐만 아니라, 본 발명의 다음의 상세한 설명은 첨부 도면과 함께 읽을 때 더 잘 이해된다. 본 발명을 설명하기 위해, 본 발명의 다양한 양태의 예시적인 실시예를 도면에 도시한다. 그러나, 본 발명은 개시된 특정 방법 및 수단으로 제한되지 않는다.

도 1은 사용자 정의 타입의 관리되는 코드(managed code) 클래스 정의를 설명하는 예시적인 코드 부분이다.

도 2는 관리되는 코드로 인스턴스화된 타입 인스턴스의 직렬화 (serialization)와 역 직렬화(deserialization)를 설명하는 블록 도면이다.

도 3은 사용자 정의 타입 객체가 보존되어있는 데이터베이스 테이블을 설명하는 도면이다.

도 4는 본 발명의 일 실시예에 따라, SqlXml 클래스의 멤버를 도시하는 테이블이다.

도 5는 본 발명의 일 실시예에 따라, SqlXml 필드를 갖는 CLR 클래스 "Employee"의 예시적인 프로그램 코드 리스팅이다.

도 6은 본 발명의 일 실시예에 따라, Employee 클래스의 새로운 인스턴스를 .NET 프로그래밍 언어로 어떻게 생성하고 어떻게 그것을 실장하는지를 나타내는 예시적인 프로그램 코드 리스팅이다.

도 7은 본 발명의 일 실시예에 따라, XML 컨텐츠를 파싱하기 위해 Employee 클래스의 인스턴스로부터 XmlReader를 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 8은 본 발명의 일 실시예에 따라, .NET 프로그래밍 언어로 Employee 클래스의 인스턴스를 업데이트하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 9는 본 발명의 일 실시예에 따라, "XmlSchemaCollection" 속성의 사용을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 10은 본 발명의 일 실시예에 따라, 클라이언트에서 XML 컨텐츠의 검증을 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 11은 본 발명의 일 실시예에 따라, 클래스 정의로부터 "XmlSchemaCollection" 속성에서 지정된 XML 스키마 컬렉션 이름을 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 12는 본 발명의 일 실시예에 따라, XML 스키마 컬렉션 이름이 알려지면, 서버에서 XML 스키마 컬렉션을 검색하는 방법을 나타내는 예시적인 프로그램 코드 리스팅.

도 13은 본 발명의 일 실시예에 따라, 검증 XmlReader를 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 14는 본 발명의 일 실시예에 따라, 클라이언트측 검증으로 업데이트를 수행하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다.

도 15는 본 발명의 일 실시예에 따라, UDT의 XML 데이터 필드에 대한 행동을 구현하기 위해, UDT를 정의하는 CLR 클래스에 동작이 추가될 수 있는 방법을 나타내는 예시적인 코드 리스팅이다.

도 16은 본 발명을 구현할 수 있는 다양한 컴퓨팅 장치를 갖춘 예시적인 네트워크 환경을 나타내는 블록 도면이다.

도 17은 본 발명을 구현할 수 있는 예시적인 컴퓨팅 장치를 나타내는 블록 도면이다.

본 발명의 요지는 법률 요구에 맞추어 전문적으로 설명하였다. 그러나, 설명 자체는 본 특허의 범위를 제한하지 않는다. 오히려, 발명자는 현재 또는 미래 의 다른 기술과 관련하여, 다른 작동 혹은 본 명세서에서 설명한 것과 비슷한 요소를 포함하여, 다른 방법으로 권리 요구한 주제가 실시될 수도 있다는 것을 심사 숙고하고있다. 또한, 여기에서, 용어 "단계"는 사용된 방법의 상이한 양태들을 포함하는 데 사용될 수 있지만, 각각의 단계의 순서가 명확하게 명시될 때를 제외하고, 여기에 개시된 디양한 단계들 간의 임의의 특정 순서를 의미하는 것로서 해석되어서는 안된다.

상술된 바와 같이, 본 발명은 사용자 정의 타입(UDT)의 필드 내에 XML 데이터를 저장하기 위한 시스템 및 방법에 관한 것이다. UDT의 필드는 XML 데이터 타입으로서 정의될 수 있고, UDT는 다른 비-XML 필드도 가질 수 있다. XNL 데이터 모델에 부합하는 데이터는 XML 필드 내에 저장될 수 있지만, 비-XML 데이터는 비-XML 필드 내에 저장된다. 따라서, 문서 순서 및 문서 구조와 같은 XML 데이터 모델의 속성(즉, 관리되는 코드로 객체에 대해 호출될 수 있는 메소드)은 UDT에 추가되어, XML 필드 뿐만 아니라 UDT의 비-XML 필드에 대해서도 동작할 수 있다. 이것은 XML 마크업을 갖는 세미-구조화된 데이터에 비지니스 논리를 추가하기 위한 프레임워크를 가능하게 한다. 또한, XML 데이터의 컨텐츠 모델은 UDT의 XML 필드에 연계된 XML 스키마 문서를 이용하여 선택적으로 설명될 수 있다.

SqlXml 클래스

본 발명의 일 양태에 따르면, CLR 클래스의 필드 내의 XML 데이터의 저장을 지원하는 새로운 클래스가 정의된다. 본 실시예에서, 이 클래스는 SqlXml이라고 불리며, 그 특정 이름이 본 발명에 결정적인 것은 아닌 것으로 이해된다. 도 4는 SqlXml 클래스의 멤버를 설명하는 테이블이다.

도 4에 도시되어 있는 바와 같이, SqlXml 클래스는 2개의 구성자를 지원한다. 한 구성자는 그 입력에 XmlReader를 수용한다. XmlReader는 XML 데이터로의 빠르고, 캐싱되지 않고, 전송-전용의 판독 액세스를 정의하는 마이크로소프트 .NET 프레임워크 추상 클래스(또는 인터페이스)이다. 이 구성자는 SqlXml 객체가 스트림 상의 XmlReader, 또 다른 SqlXml 인스턴스, 또는 XmlReader가 이용가능한 임의의 클래스로부터 인스턴트화될 때 유용하다. XML 컨텐츠는 XmlReader 인터페이스를 통해 판독되기 때문에, 적격의 검사가 이 구성자의 일부분으로서 일어난다. 다른 구성자는 입력으로서 스트림을 수용하고, 그 구성자에서 적격의 검사가 스킵될 때 사용된다. 다른 구성자도 가능하다.

CreateReader() 메소드는 SqlXml의 (XML) 컨텐츠가 검색되는 XmlReader를 리턴한다. XmlReader를 지원하는 것은 XML 컨텐츠에 대한 매우 유연한 메커니즘을 제공한다. 예를 들어, XPathDocument 또는 XPathNavigator는 서버로부터 XML 데이터 타입 값에 대해 인스턴스화될 수 있다.

SqlXml 클래스는 메모리가 없고, 동기식의 CreateReader() 호출이 허용된다. 다중의 CreateReader() 호출은 XmlReader의 상이한 인스턴스들을 리턴한다. 각각의 그러한 인스턴스는 SqlXml 객체에 의해 캡슐화된 XML 컨텐츠의 시작부에 초기화된다. 이것은 SqlXml의 인스턴스가 XML 판독자의 새로운 인스턴스가 생성될 수 있는 함수 및 프로시저에 전달되게 한다.

SqlXml 멤버 M의 값을 업데이트하기 위하여, 스트림에 기록하고, 스트림에 대한 XmlReader를 인스턴스화하고, XmlReader 또는 스트림으로부터 새로운 SqlXml 객체 M1을 인스턴스화하는 데 XmlWriter를 사용한다. XmlWriter는 XML 추천으로 W3C 확장가능 마크업 언어(XML) 1.0 및 네임스페이스에 부합하는 XML 데이터를 포함하는 스트림 또는 파일을 생성(기록)하는 빠르고, 캐싱되지 않고, 전송-전용의 수단을 정의하는 .NET 프레임워크 추상 클래스(또는 인터페이스)이다. XmlTextWritter는 XmlWriter 인터페이스를 구현하는 .NET 프레임워크 클래스이다. 다음의 XML 스트링:

<x:item/>

</x:root>

은 다음의 C# 코드 프레그먼트:

XmlTextWriter w=new XmlTextWriter();

w.WriteAttributerString("xmlns", "x", nell, "urn:1");

w.WriteStartElement("item", "urn:1");

w.WriteEndElement();

w.WriteStartElement("item", "urn:1");

w.WriteEndElement();

에 의해 생성될 수 있다.

SqlXml 객체 M1은 M에 할당된다. 이것은 소스 객체 M1의 현재 상태를 M에 복사한다. XML 컨텐츠를 업데이트하는 데 사용될 수 있는 XmlWriter 객체를 리턴하는 CreateWriter()와 같은 SqlXml에 대한 다른 메소드도 가능하다.

CLR 클래스에서 SqlXml 사용

본 발명의 본 실시예에 따르면, CLR 클래스의 하나 이상의 멤버들은 새로운 SqlXml 타입으로서 정의될 수 있다. SqlXml를 뒷받침하는 원시 CLR 타입은 XmlReader가 획득될 수 있는 스트림을 제공하는 것이며, 스트림은 직접적으로 액세스될 수 없고 XmlReader를 통해서만 액세스될 수 있다. 이것은 또한, 2개의 구성자를 지원하는데, 그 중 하나는 XmlReader이고 다른 하나는 스트림이다.

도 5는 SqlXml 필드를 갖는 CLR 클래스 "Employee"의 예시적인 프로그램 코드 리스팅이다. 도시되어 있는 바와 같이, Employee 클래스는 서버에서 프리미티브 SQL 타입에 맵핑되는 몇몇의 "sqltypes" 멤버들을 갖는다. Resume 멤버의 타입은 SqlXml이다. 그것은 서버에서 XML 데이터 타입, 및 CLR의 스트림에 의해 뒷받침된다. 두 경우에서, XML 컨텐츠는 XmlReader를 통해 액세스가능하다.

SqlXml 필드를 갖는 사용자-정의 타입 생성

배경기술 섹션에서 설명한 바와 같이, .NET 프로그래밍 언어의 관리 클래스로부터 SQL의 사용자-정의 타입을 생성하기 위해, 사용자는 우선, CREATE ASSEMBLY문을 사용하여 타입의 정의를 포함하는 어셈블리를 등록한다. 사용자-정의 타입은 다음과 같이 CREATE TYPE문을 사용하여 생성된다.

CREATE TYPE[type-schema-name].udt-name

EXTERNAL NAME assembly-name[:class-name]

본 발명에 따르면, SQL 사용자-정의 타입 udt-name은 (타입 안된) XML 데이터 타입의 하나 이상의 필드 X1, X2 등을 가질 수 있고, 이들은 UDT에 대한 CLR 클래스 C 내의 SqlXml 필드 M1, M2 등에 대응한다. 상술되고 도 2에 도시된 바와 같이, 타입 udt-name의 인스턴스의 클래스 C로의 직렬화 및 역 직렬화는 보통 방식으로 수행된다. 이 경우에 타입을 생성하기 위한 모든 일반적 규칙이 보유된다. udt-name의 XML 필드는 큰 이진 SQL 타입으로서 이진XML이라고 불리는 내부 표시로 저장된다.

사용자-정의 타입이 생성되면, 테이블 또는 뷰에서 컬럼 타입으로서 사용될 수 있고, XML 필드 없이 임의의 사용자-정의 타입과 같이 SQL 변수 및 파라미터로서 사용될 수 있다. 예로서, udtEmp라고 불리는 상술된 Employee 클래스에 기초한 UDT는 다음과 같이 생성된다.

CREATE TYPE udtEmp

EXTERNAL NAME myAssembly:Employee

udtEmp UDT는 fName 및 lName에 대한 nvarchar(4000) 타입, Age 필드에 대한 float 타입 등의 필드들을 가질 것이다. 클래스 Employee의 SqlXml 멤버 Resume는 udtEmp의 타입 안된(즉, 임의의 XML 스키마 연관 없이) XML 데이터 파일 필드 Resume에 맵핑된다.

사원 테이블 tabEmployee는 다음과 같이 integer 컬럼인 ID, 및 udtEmp 컬럼인 Employee로 생성될 수 있다.

CREATE TABLE tabEmployee(ID integer, udtEmp EmpCol)

테이블 생성은 사용자-정의 타입 udtEmp에 대해 바인딩하는 스키마를 설정한다. 2개의 컬럼에 대한 값을 지원함으로써 테이블 tabEmployee에 로우가 삽입될 수 있다. EmpCol의 Resume 필드에 삽입된 XML 값은 삽입 시기에 적격성에 대해 검사받는다.

인스턴스 레벨에서, Employee 객체는 SqlXml 멤버 Employee.Resume를 EmpCol.Resume 필드 내에 저장한 상태에서, udtEmp의 인스턴스에 직렬화된다. 반대로, EmpCol의 인스턴스는 EmpCol.Resume 필드의 값을 Employee.Resume 멤버에 로드한 상태에서, Employee 객체에 역 직렬화된다.

또 다른 예로, 다음의 T-SQL문이 실행된다고 가정하자.

SELECT EmpCol.Resume

FROM tabEmployee

의미적으로, (udtEmp 타입의) 컬럼 EmpCol 내의 각각의 값은 CLR 내의 타입 Employee의 객체로 역 직렬화된다. 특히, XML 데이터 타입 필드 EmpCol.Resume는 SqlXml 멤버 Employee.Resume에 로드되며, 이것은 XML 데이터 타입으로서 T-SQL 계층에 리턴된다. 한가지 최적화는 EmpCol.Resume의 값을 직접 추출하고 Employee.Resume 멤버의 값을 추출하기 위해 역 직렬화를 회피하는 것이다.

도 6은 .NET 프로그래밍 언어로 Employee 클래스의 새로운 인스턴스를 생성하고 그것을 실장하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다. 이 예에서, 새로운 Employee 객체가 생성된다. 그것의 비-XML 필드들은 보통의 방식으로 값을 할당받는다. XML 필드 Resume에 대해서, XmlTextReader 판독자는 스트링 값("여기에서는 XML 컨텐츠")에 대해 생성된다. 새로운 SqlXml 객체는 판독기에 대해 인스턴스화되고 Resume 필드에 할당된다. 상술된 바와 같이, XmlTextReader는 XmlReader 인터페이스를 구현하는 .NET 프레임워크 클래스이다.

XML 컨텐츠는 XmlReader를 이용하여 Resume 필드의 내부 저장소에 복사된다. 판독자를 통한 검색은 XML 컨텐츠에 대한 적격성 검사를 야기한다. XmlReader가 획득될 수 있는 임의의 객체는 충분할 것이다. 따라서, 파일로부터 판독하거나 임의의 다른 SqlXml 인스턴스로부터 XmlReader를 획득할 수 있다.

도 7은 XML 컨텐츠를 파싱하기 위해 Employee 클래스의 인스턴스로부터 XmlReader를 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다. 이 리스팅에서, Emp.Resume.CreateReader()는 XML 컨텐츠가 검색될 수 있는 (비확인) XmlReader를 리턴한다. 객체 reader1 및 reader2는 XML 컨텐츠의 시작부에 초기화된다. 이들은 SqlXml이 메모리가 없기 때문에 서로에 대해 독립적이다.

도 8은 .NET 프로그래밍 언어로 Employee 클래스의 인스턴스를 갱신하는 방 법을 나타내는 프로그램 코드 리스팅의 예이다. Employee 객체 Emp의 비-XML 필드들은 보통의 방식으로 갱신된다. 새로운 XML 컨텐츠("여기에서는 새로운 XML 컨텐츠")는 스트림에 기록되고, XmlReader 판독자는 스트림에 대해 구성되고, 새로운 SqlXml 객체는 판독자에 대해 구성된다. 구성된 SqlXml 객체는 대응하는 필드 Emp.Resume에 할당된다. 이것은 XML 컨텐츠가 Emp.Resume에 복사되게 한다. 이것이 "블라인드(blind)" 기록의 일례이다. 점진적인 갱신에 있어서, 어플리케이션은 Emp.Resume로부터 XML 판독자를 획득하고, 그것으로부터 판독하고, 갱신된 컨텐츠를 XML 기록자에 기록할 수 있다. 갱신 컨텐츠는 Emp.Resume의 현재 컨텐츠 및 그것에 대한 변경(예를 들어, 새로운 전화번호 추가)에 기초한다.

타입지정된 XML

본 발명의 또 다른 양태에 따르면, UDT 내의 XML 필드는 서버에서 XML 스키마 컬렉션에 바인딩될 수 있다. XML 스키마 컬렉션은 상이한 XML 스키마에 관련된 데이터 인스턴스가 관계형 데이터베이스의 동일한 컬럼 내에 저장되게 하는 SQL SERVER의 새로운 개념이다. 본 발명에 따르면, XML 스키마 컬렉션 개념은 상술된 바와 같이, SqlXml을 정의한 UDT의 필드들(즉, 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 컬럼은 인덱싱될 수 있고, 그러한 컬럼 내의 XML 값은 쿼리될 수 있다. 또한, XML 컬럼은 그 컬럼 내의 XML 데이터 값들을 스키마에 부합시키기 위해 XML 스키마를 이용하여 "타입지정"될 수 있다. 주어진 XML 스키마에 부합하는 XML 데이터 값이 관계형 데이터베이스에서 발견될 때, 데이터는 스키마의 윤곽에 따라 액세스되고, 결과적으로, 데이터는 효율적으로 번역될 수 있다.

그러나, 관계형 데이터베이스의 동일한 컬럼에서, 하나가 아닌 여러 스키마에 부합하는 XML 데이터 값을 저장하려고 시도할 때 문제가 발생한다. 하나의 값은 책의 제목, 책의 저자, 출판사, 저작권 년도 등을 지정하는 책에 관한 XML 데이터일 수 있다. 또 다른 값은 DVD 제목, 배우, 감독, 장르, 등급, 출판 년도 등을 지정하는 DVD에 관한 XML 데이터일 수 있다. 모든 미디어 즉, 책 및 DVD에 대한 결정을 한번에 내리는 것에 관련된 데이터 처리 효율성을 위해, 특정 컬럼에 책과 DVD 모두를 저장하는 것이 바람직하다고 가정하면, 그 컬럼 내의 XML 데이터에 대한 규칙을 이해하고 시행하는 데에 어느 스키마가 사용되어야 하는지에 관한 문제 가 발생한다. 이전에는, 하나의 컬럼 내에는 하나의 스키마에 부합하는 데이터만이 저장될 수 있었다. 컬럼을 식별하는 데 사용될 스키마는 컬럼의 꼭대기에서 식별되고, 그 식별된 스키마에 부합하지 않은 임의의 데이터 인스턴스는 에러를 발생할 것이다.

XML 스키마 컬렉션의 새로운 개념은 복수의 상이한 스키마에 연계된 XML 데이터가 XML 스키마 컬렉션 객체를 통해 관계형 데이터베이스의 동일한 컬럼에 저장되게 함으로써 이 문제를 해결한다. XML 스키마 컬렉션은 XML 스키마 네임스페이스에 대한 컨테이너로서 활동하는 제1 클래스 SQL SERVER 객체가다. 사용자는 XML 스키마 컬렉션을 이용하여 XML 컬럼, 파라미터 및 변수를 억제할 수 있다. 이것은 그들이 억제하는 XML 스키마 컬렉션 내의 XML 스키마 네임스페이스들 중 임의의 하나에 부합하는 XML 데이터의 인스턴스를 저장하게 한다.

따라서, XML 스키마 컬렉션 객체는 XML 스키마 네임스페이스에 대한 컨테이너인 제1 클래스 SQL 객체가다. 하나의 비제한적 구현예에서, 그것은 3-파트 이름에 의해 식별된다. XML 스키마 컬렉션에 대한 SQL 식별자의 범주는 그것이 생성되는 관계형 스키마이다. 각각의 XML 스키마 컬렉션은 복수의 XML 스키마 네임스페이스 URI(universal resource identifier)를 포함할 수 있다. XML 스키마 네임스페이스는 XML 스키마 컬렉션 객체 내에서 유일하고, 사용자는 XML 스키마 컬렉션을 사용하여 XML 컬럼을 제약할 수 있다. 이것은 그들이 XML 스키마 컬렉션에 속하는 잠재적으로 관련없는 XML 스키마에 대해 문서를 제약하게 한다.

상술한 바와 같이, 본 발명의 양태에 따라, XML 스키마 컬렉션의 개념은 EDT 의 필드에 확장된다. 즉, UDT의 XML 필드는 서버에서 XML 스키마 컬렉션에 바인딩될 수 있다. 서버에서 UDT의 XML 필드를 XML 스키마 컬렉션에 바인딩하는 것은, XML 필드의 각각의 인스턴스가 그 스키마 컬렉션 내의 XML 스키마들 중 하나에 따라 유효하다는 것을 의미한다. 또한, XML 스키마에 기초하여 저장이 최적화되는 한편, XML 데이터 타입 메소드를 이용한 쿼리는 타입 참조에 대한 XML 스키마를 이용하여 최적화된다.

다음은 .NET 언어로 타입지정된 XML을 지원하는 요구조건이다. 첫째, 클래스 멤버를 타입지정하는 XML 스키마는 실행시간이 아니라 클래스 정의 시간에 지정될 수 있다. 즉, 정의는 평서문이어야 한다. 둘째, XML 판독자에 연계된 XML 스키마 세트는 동적 세트이어야 한다. 즉, 세트 내의 스키마는 변경될 수 있다(예를 들어, 윈도우 쉘 내의 커스텀 속성의 생성에 대응하는 새로운 엘리먼트가 추가됨). 스키마에서 엘리먼트를 제공하는 것이 허용되어야 한다. 또한, 스키마 세트에 새로운 XML 스키마가 추가될 수 있게 한다(예를 들어, 파워포인트와 같은 새로 설치된 어플리케이션은 스키마 세트에 자신의 스키마를 추가함). 또한, 스키마 세트에서 스키마가 삭제될 수 있다(예를 들어, 파워포인트가 프로그램 삭제되고, 그것의 스키마가 XML 스키마 컬렉션에서 제거되게 함). 스키마는 새로운 버전으로 대체될 수도 있다.

서버에서 UDT의 XML 필드를 XML 스키마 컬렉션에 바인딩하는 것을 지원하기 위하여, 본 발명의 본 실시예에서, 그 값이 스트링인 "XmlSchemaCollection"이라고 불리는 새로운 속성이 배경기술 섹션에서 설명된 SqlUDTField 주석을 이용하여 SqlXml 멤버에 대해 지정될 수 있다. 이 속성의 값은 UDT의 대응하는 XML 필드를 타입지정하는 서버에서 XML 스키마 컬렉션의 이름을 표시한다. 이것은 1-파트 이름(다중파트 이름과 반대)이며, 이것은 임의의 데이터베이스 및 임의의 관계형 스키마를 갖는 클래스 정의를 이용하는 유연성을 제공한다. 원시 CLR 컨텍스트에서, SqlXml 멤버에 대한 SqlUDT 주석은 무시된다. 대안적으로, 데이터베이스, 관계형 스키마 및 XML 스키마 컬렉션 이름을 지정하는 3-파트 이름일 수 있다.

본 실시예에서, "XmlSchemaCollection"은 SqlXml 멤버에 대해 허용된 유일한 속성이며, 다른 속성들은 지정되는 경우, 그 속성이 허용되지 않는 보통의 에러에 귀착한다. 다른 속성은 이 문서내에서 허용될 수 있다. "XmlSchemaCollection" 속성을 지정하는 SqlXml 멤버 M의 신택스는 다음과 같다.

[SqlUDTField (XmlSchemaCollection="XML-Schema-Collection-Name")]

SqlXml M;

"XmlSchemaCollection" 속성은 임의의 XML 스키마로의 SqlXml 멤버 M의 바인딩을 허용하지 않는다. 어플리케이션이 M으로부터 검증 XmlReader을 획득하기를 원하는 경우, 그 어플리케이션은 XML 스키마를 검증 XmlReader에 연계시킬 책임을 갖는다. 즉, SqlXml 클래스는 "XmlSchemaCollection" 속성의 존재에도 불구하고, 검증 XmlReader가 아니라 M에 대한 비검증 XmlReader를 계속해서 제공한다. 대안적으로, 속성은 XML 스키마 바인딩을 야기하고 검증 판독기를 리턴할 수 있다.

"XmlSchemaCollection" 속성의 값으로서 지정된 이름 XML-Schema-Collection-Name을 갖는 XML 스키마 컬렉션은 서버 메타-데이터에 존재해야 한다. 특히, 그것은 UDT udt-name이 생성되는 스키마와 동일한 관계형 스키마 내에 존재해야 한다. 스키마 바인딩은 udt-name으로부터 "XML-Schema-Collection-Name"에 대해 설정된다. XML-Schema-Collection-Name이 존재하지 않으면, CREATE TYPE문은 사용자-정의 타입 udt-name을 생성하는 데 실패한다.

본 실시예에서, "XmlSchemaCollection" 속성에 대한 동일한 값을 갖는 2개의 SqlXml 멤버는 서버에서 XML 스키마 컬렉션을 공유할 것이다. 이것은 어플리케이션이 저장을 최적화하게 한다. 설계는 보다 더 보편적이며, XML 스키마 컬렉션이 복수의 어셈블리의 복수의 클래스의 복수의 멤버들 사이에서 공유되게 한다.

CLR 클래스의 인스턴스는 "XmlSchemaCollection" 속성 명세서를 갖는 SqlXml 멤버를 포함하는 모든 클래스 멤버에 대해 보통의 방식으로 직렬화된다. 이 SqlXml 멤버는 UDT 인스턴스의 타입지정된 XML 필드 내에 저장되고, 삽입 및 데이터 수정 동안 XML 스키마에 대한 검증이 일어난다.

UDT 직렬화에 대해, 각각의 SqlXml 멤버의 XML 컨텐츠만이 직렬화되고, XmlSchemaSet 내의 XML 스키마는 직렬화되지 않는다. XML 스키마는 개별적으로 서버의 XML 스키마 컬렉션에 추가되거나 그로부터 삭제되어야 한다.

역 직렬화 동안, UDT의 필드는 CLR 클래스의 대응하는 멤버에 로드된다. 타입지정된 XML 필드에 대하여, 인스턴스 데이터는 SqlXml 객체로서 노출된다. 연계된 XML 스키마 컬렉션은 사용되지 않는다. 사용자는 이하에 설명되는 바와 같이, XML 스키마 컬렉션을 클라이언트 내의 XmlSchemaSet 객체에 로드할 수 있다.

도 9는 "XmlSchemaCollection" 속성의 사용을 나타내는 프로그램 코드 리스 팅의 일례이다. 도 9의 정의는 사용자-정의 타입 udtTypedEmp의 XML 필드 "Resume"를 타입지정하는 것이 바람직하다고 가정한다. SqlUDTField 주석은 UDT의 TypedEmployee.TypedResume에 대응하는 XML 필드를 타입지정하는 서버의 XML 스키마 컬렉션 이름 "myEmployeeSchema"을 지정한다.

다음의 일련의 동작은 타입지정된 XML 필드를 가지고 UDT를 생성하는 데 사용된다.

(1) XML 스키마 컬렉션을 생성:

Create XML SCHEMA COLLECTION myEmployeeSchema

AS '<xs:schema xmlns="book">...</xs:schema>'

(2) CLR 클래스 TypedEmployee를 생성

(3) 어셈블리를 생성

(4) 사용자-정의 타입 udtTypedEmployee를 생성

XML 스키마 컬렉션 myEmployeeSchema는 사용자-정의 타입 udtTypedEmployee가 생성될 때 서버에 존재해야 한다. 그렇지 않으면, 사용자-정의 타입의 생성은 실패한다.

XML 스키마 검증

본 실시예에서, 검증 XmlReader를 통해 XML 컨텐츠가 검색되거나, 검증 XmlWriter를 이용하여 XML 컨텐츠가 기록될 때, 서버에서 XML 스키마 문서(XSD) 검증이 일어난다. 본 실시예에서, 서버에서는, UDT 인스턴스가 컬럼에 삽입되거나 갱신될 때 XSD 검증이 일어난다. 따라서, 본 실시예에서, 새로운 SqlXml 객체가 비검증 XmlReader에 대해 구성되고 "XmlSchemaCollection" 속성이 지정된 SqlXml 멤버에 할당될 때, 어떤 XSD 검증도 일어나지 않는다.

또 다른 예를 들면, 개발자 또는 다른 사용자는 클라이언트측 검증 없이 TypedEmployee 클래스의 새로운 인스턴스를 생성하기를 원할 수 있다. 그러한 경우에, 프로그램 코드는 SqlUdet 주석 없이 SqlXml 멤버에 대한 코드와 정확히 동일하다(도 6 참조). 그러나, 클라이언트의 XML 컨텐츠의 검증이 요구되면, 그것은 도 10의 예시적인 프로그램 코드 리스팅에 나타난 방식으로 달성될 수 있다. 이 경우는 XmlSchemaSet mySchemaSet가 생성되고 실장되는 클라이언트측 검증 없는 경우와 다르며, 스트림에 대한 검증 XmlWriter valWtr를 생성하는 데 사용된다. valWtr를 통해 기록된 XML 컨텐츠는 mySchemaSet에 따라 검증된다. 스트림으로부터 획득된 비-검증 XmlReader 판독자는 newEmp.TypedResume로의 할당을 위해 SqlXml의 새로운 인스턴스를 구성하는 데 사용된다. 코드를 작성하는 다른 방법들이 있음을 이해해야 한다. 예를 들어, 검증 판독자는 클라이언트측 검증을 위해 검증 기록자 대신에 사용될 수 있다.

XML 스키마 검증의 또 다른 양태에 따라, 본 실시예에서, 클래스 정의로부터 "XmlSchemaCollection" 속성에 지정된 XML 스키마 컬렉션 이름을 획득하는 것이 가능하다. 도 11의 예시적인 프로그램 코드 리스팅은 이것이 어떻게 이루어질 수 있는지를 나타낸다. 보여지는 바와 같이, "XmlSchemaCollection" 속성을 제외하고는 XML-특정적인 어떤 것도 없다.

도 11에 도시되어 있는 바와 같이, 클래스 정의로부터 XML 스키마 컬렉션 이 름이 알려지면, XML 스키마 컬렉션은 서버로부터 검색되어 XmlSchemaSet 객체를 실장할 수 있다. 이 객체는 검증 XmlReader 또는 XmlWriter를 생성하는 데 사용된다. 도 12의 예시적인 프로그램 코드 리스팅이 이 메커니즘을 나타낸다.

데이터베이스 접속은 서버로부터 XML 스키마 컬렉션을 검색하기 위해 요구된다. 인-프로세스(in-process) 제공자에게 있어서, 그것은 SqlContext 객체로부터 획득된다. 프로세스외(out-of-process) 제공자에게 있어서, 어플리케이션은 (데이터가 검색되는 것과는 다를 수 있는) 접속을 공급한다. SQL 문은 파라미터로서 지정된 XML 스키마 컬렉션 이름을 이용하여 카탈로그 뷰에 대해 실행된다. 고유 함수 XML_SCHEMA_COLLECTION()은 XML 데이터 타입 컬럼에서 스키마 문서를 검색하는 데 사용되며, 이것은 SqlXml 클래스에 역 직렬화된다. 각각의 스키마 문서는 SqlXml 객체로부터 획득된 XmlReader를 통해 XmlSchemaSet 객체에 추가된다.

SqlXml 멤버 TypedEmployee.TypedResume로부터 비-검증 판독자를 획득하기 위해, 프로그램 코드는 SqlUdt 주석 없는 SqlXml 멤버에 대한 것과 동일하다(도 7 참조). 도 13은 검증 XmlReader를 획득하는 방법을 나타내는 예시적인 프로그램 코드 리스팅이다. 이 예에서, 검증 XmlReader valRdr은 SqlXml 멤버 TypedEmployee.TypedResume로부터 획득된 비-검증 판독자 nonValRdr에 대해 생성된다. valRdr로부터 임의의 것이 판독되기 전에, XmlSchemaSet 객체 mySchemaSet이 추가된다. 검증 타입은 XSD일 것으로 지정된다. 검증된 컨텐츠는 이제 검증 판독자를 통해 판독될 수 있다.

기존 XML 값을 갱신할 때, 본 실시예에서, SqlXml 멤버는 SqlUdt 주석 없는 SqlXml 멤버에 대한 것과 동일한 코드를 이용하여 클라이언트측 검증 없이 갱신될 수 있다(도 8 참조). 도 14의 예시적인 프로그램 코드 리스팅은 클라이언트측 검증을 가지고 갱신을 수행하는 방법을 나타낸다. XML 스키마 컬렉션은 서버로부터 XmlSchemaSet 객체 mySchemaSet에 검색된다. 이것은 스트림에 대한 검증 XmlWriter valWtr을 생성하는 데 사용된다. XML 컨텐츠는 valWtr에 기록되고, 비-검증 XmlReader 판독자는 스트림으로부터 획득되고, TypedEmp.TypedResume는 판독자로부터 구성된 새로운 SqlXml 객체를 할당받는다.

UDT의 XML 필드의 조작

본 발명에 따라, UDT의 XML 필드에 쿼리하고 그것을 갱신하는 것이 가능하다. 예를 들어, 다음과 같이, employee 테이블 tabEmployee(상술된 예 참조) 내의 XML 필드 Resume에 쿼리하는 것이 가능하다.

SELECT EmpCol.Resume.query('//Education')

FROM tabEmployee

WHERE EmpCol.AnnualSalary()>40000

AND EmpCol.fName='John'

AND EmpCol.Resume.value('//Address/ZipCode', 'int')=98052

표현식 EmpCol.Resume는 UDT의 XML 데이터 타입 필드를 유도하기 때문에, XML 데이터 타입에 대한 "쿼리" 및 "값" 함수가 XML 인스턴스로의 드릴다운에 사용될 수 있다. 비-XML 필드는 보통 방식으로 액세스된다. 이 쿼리는 또한, 사용자-정의 타입 udtEmp에 대한 함수 AnnualSalary()의 호출을 나타낸다.

갱신의 일례로, 이름이 "John"인 종업원의 우편번호가 98052로 변경된다고 가정하자. 이 갱신은 다음의 문장을 이용하여 달성될 수 있다.

UPDATE tabEmployee

SET EmpCol.Resume.modify('Update //ZipCode to 98052')

Where EmpCol.fname='John'

상기 설명에서와 같이, 본 발명은 모두 사용자 정의 타입(UDT)의 단일 인스턴스 내에 있는 구조적, 세미-구조적 및 비구조적 데이터를 모델링하기 위한 프레임워크 및 방법을 제공한다. 특히, 본 발명은 XML 데이터 모델을 UDT의 필드에 확장한다. 따라서, 문서 순서 및 문서 구조와 같은 XML 데이터 모델의 속성은 UDT의 인스턴스 내에서 보존될 수 있다. 상술된 바에 따르면, XML 데이터의 컨텐츠 모델은 선택적으로, UDT의 XML 필드에 연계된 XML 스키마 문서를 이용하여 설명될 수 있다.

또한, UDT는 관리되는 코드의 클래스에 의해 정의되기 때문에, 객체 동작을 나타내는 코드(즉, 관리되는 코드로 객체 상에서 호출될 수 있는 메소드)는 UDT에 추가되어, XML 필드 뿐만 아니라 UDT의 비-XML 필드에 대해서도 동작할 수 있다. 이것은 XML 데이터에 비지니스 논리를 추가하기 위한 프레임워크를 가능하게 한다.도 15는 동작이 타입 SqlXml로서 정의되는 필드에 대한 동작을 구현하기 위해 UDT를 정의하는 CLR 클래스에 추가될 수 있는 방법을 도시하는 예시적인 코드 리스팅이다. 이 예에서, 지정된 XSL(eXstensible Stylesheet Language) 파일에 따라 Resume(XML) 데이터를 변형하는 동작이 추가된다. 보여지는 바와 같이, 동작은 클 래스 Employee에 추가된 메소드 TransformXml()에 의해 구현된다. 변형된 값은 XML 데이터 타입 SqlXml로서 리턴된다. 도면의 아래부분의 SQL문에 의해 보여지는 바와 같이, 이 메소드는 Employee 클래스로부터 생성된 UDT의 인스턴스에 대해 호출될 수 있다. 따라서, 이 예에서 설명된 바와 같이, XML 데이터를 포함하는 UDT의 필드에 대한 동작을 구현하는 것이 바람직하다. 구현될 수 있는 동작은 가상적으로 무제한이며, XML 데이터에 비지니스 논리를 추가하기 위한 강력한 툴을 제공한다.

위 설명에서 명백해지는 바와 같이, 다양한 시스템, 메소드, 및 본 발명의 관점 전부 또는 부분은 하드웨어, 소프트웨어, 혹은 이 둘의 결합으로 실시될 수 있다. 소프트웨어에서 구현되는 경우, 본 발명의 메소드와 장비, 또는 그 특정 양태나 부분은, 프로그램 코드(즉, 명령문) 형태로 실현될 수 있다. 이 프로그램 코드는 플로피 디스켓, CD-ROM, CR-RW, DVD-ROM, DVD-RAM, 자기 테이프, 플래시(flash) 메모리, 하드 디스크 드라이브, 또는 임의의 기계 판독 가능 저장 매체를 포함하여, 자기적, 전기적, 혹은 광학적 저장 매체와 같은 컴퓨터 판독 가능 매체에 저장되나, 이에 제한을 두지 않으며, 그 중에 컴퓨터 또는 서버와 같은 기계에 의해 프로그램 코드가 로드되어 실행되면, 그 기계는 본 발명을 실행한 장비가 된다. 프로그램 코드가 실행되는 컴퓨터는 일반적으로 프로세서(processor), 프로세서에 의해 판독 가능한 저장 매체(휘발성 및 비 휘발성 메모리 및/혹은 저장 요소를 포함), 적어도 하나의 입력 장치, 및 적어도 하나의 출력 장치를 포함한다. 프로그램 코드는 하이 레벨 절차적 또는 객체 지향적 프로그래밍 언어로도 구현될 수 있다. 바꾸어서, 프로그램 코드는 어셈블리 또는 기계 언어로 구현될 수 있다. 어떤 경우든, 언어는 컴파일러되거나 번역된 언어이다.

본 발명은 로컬 네트워크, 광역 네트워크, 인터넷 또는 인트라넷, 또는 전송의 임의의 다른 형태를 포함하여 전선, 케이블, 광 섬유, 네트워크와 같은 전송 매체를 통하여 전송되는 프로그램 코드의 형태로 실시될 수 있다. 그 중에, 프로그램 코드가 컴퓨터와 같은 기계에 의해 수신 로드되어 실행되면, 그 기계는 본 발명을 실행한 장비가 된다.

다 목적용 프로세서에서 구현되면, 프로그램 코드는 프로세스와 결합하여 특정 논리 회로처럼 비슷하게 작용하는 유일한 장비를 제공한다.

또한, 본 발명은 임의의 컴퓨터 또는 기타 클라이언트 또는 서버 장치와 관련하여 구현될 수 있는데, 그것들은 컴퓨터 네트워크의 부분으로, 또는 분산 컴퓨팅 환경에 배포될 수 있다. 이에 관하여, 본 발명은 임의의 개수의 메모리 혹은 저장 유닛, 그리고 임의의 개수의 저장 유닛 혹은 볼륨(volume)에 걸쳐 일어나는 임의의 개수의 응용 프로그램 및 프로세스를 갖춘 임의의 컴퓨터 시스템 또는 환경에 관련되며, 이것은 본 발명에 따라 데이터베이스 저장소에 객체를 보존하기 위한 프로세스와 관련하여 사용될 수 있다. 본 발명은 원격 또는 로컬 저장 장치를 갖춘 네트워크 환경 또는 분산 컴퓨팅 환경에 배포된 서버 컴퓨터 및 클라이언트 컴퓨터 환경에 적용할 수 있다. 본 발명은 또한 프로그래밍 언어 기능, 번역, 그리고 원격 또는 로컬 서비스와 관련하여 정보의 발생, 수신 및 전송에 대한 실행 능력을 갖춘 단독 컴퓨팅 장치에도 적용할 수 있다.

분산 컴퓨팅은 컴퓨팅 장치와 시스템 간의 교환으로 컴퓨터 자원 및 서비스의 공유를 촉진한다. 이들 자원과 서비스는 정보의 교환, 캐시 저장 장치, 및 파일 디스크 저장 장치를 포함한다. 분산 컴퓨팅은 네트워크 연결성의 이점을 취하여, 클라이언트로 하여금 그들의 수집력을 강화하여 기업 전체에 이익을 준다. 이에 관하여, 다양한 장치가 본 발명의 객체 보존 방법과 관련하여 이행되는 프로세싱을 내포하는 응용 프로그램, 객체 또는 자원을 갖춘다.

도 16은 예시적인 네트워크 또는 분산 컴퓨팅 환경의 개념 도면을 제시한다. 분산 컴퓨팅 환경은 컴퓨팅 객체(10a, 10b, 등) 및 컴퓨팅 객체 혹은 장치(110a, 110b, 110c, 등)를 포함한다. 이들 객체는 프로그램, 메소드, 데이터 저장소, 프로그램 가능 논리, 등을 포함한다. 객체는 PDA, 텔레비전, MP3 플레이어, 개인 컴퓨터, 등과 같은 동일한 또는 다른 장치들의 부분을 포함할 수 있다. 각 객체는 통신 네트워크(14)를 통해 다른 객체와 통신할 수 있다. 이 네트워크 자체는 도 16의 시스템에 서비스를 제공하는 다른 컴퓨팅 객체와 컴퓨팅 장치를 포함하며, 다중 상호연결된 네트워크를 나타낸다. 본 발명의 관점과 일치하여, 각 객체(10a, 10b, 등 혹은 110a, 110b, 110c, 등)는 본 발명의 객체 보존 방법을 구현하기 위해 사용되는 프로세스의 사용을 요청하기 위해 API 혹은 다른 객체를 사용할 수도 있는 응용 프로그램, 소프트웨어, 펌웨어 및/또는 하드웨어를 포함한다.

객체(110c)가 다른 컴퓨팅 장치(10a, 10b, 등 또는 110a, 110b, 등)에 의해 관리되는 것은 높게 평가된다. 이와 같이, 비록 제시된 물리적 환경은 컴퓨터로 연결된 장치를 보여주지만, 이런 설명은 단지 예시적이며 물리적 환경은 PDA, 텔레 비전, MP3 플레이어, 등과 같은 다양한 디지털 장치와 인터페이스, COM 객체와 같은 소프트웨어 객체 및 등등을 포함하여 다르게 제시되거나 설명될 수 있다.

분산 컴퓨팅 환경을 지원하는 다양한 시스템, 컴포넌트, 및 네트워크 구조가 있다. 예를 들어, 컴퓨팅 시스템은 로컬 네트워크 또는 광역 분산 네트워크 단위로 유선 또는 무선 시스템에 의해 함께 연결된다. 일반적으로, 많은 네트워크가 인터넷에 연결 되어 있어, 광역 분산 컴퓨팅에 기반 구조를 제공하고 다양한 네트워크를 포함한다. 예시적인 통신에 사용되는 어떤 기반 구조도 본 발명의 부수 사항이다.

인터넷은 보통 TCP/IP 프로토콜 슈트를 사용하는 네트워크와 게이트웨이의 집합을 일컬으며, TCP/IP 프로토콜 슈트는 컴퓨터 네트워킹 기술 분야에서 유명하다. TCP/IP는 "Transmission Control Protocol/Internet Protocol"의 두문자어이다. 인터넷은 사용자가 네트워크를 통해 상호 대화 및 정보 공유를 하게 허용하는 네트워킹 프로토콜을 실행하는 컴퓨터에 의해 연결된 지리적으로 분산되어 있는 원격 컴퓨터 네트워크 시스템으로 설명할 수 있다. 이런 광범위한 정보 공유때문에, 인터넷과 같은 원격 네트워크는 여태까지 일반적으로 개발자가 기본적으로 아무 제한없이 특정 태스크 또는 서비스를 수행하는 응용 소프트웨어를 설계할 수 있는 오픈 시스템으로 발전되어있다.

이와 같이, 네트워크 기반 구조는 클라이언트/서버, 피어-투-피어(peer-to-peer), 혼합 아키텍처와 같은 네트워크 토폴로지(topology)의 호스트(host)를 가능케 한다. "클라이언트"는 아무 관계없는 다른 클래스 또는 그룹의 서비스를 사용 하는 다수의 클래스 또는 그룹이다. 그러므로, 컴퓨팅에서, 클라이언트는 프로세스이다, 즉, 대략적으로 다른 프로그램에 의해 제공되는 서비스를 요청하는 명령문 또는 태스크의 집합이다. 클라이언트 프로세스는 다른 프로그램 또는 서비스 자체에 관한 처리 세부 사항을 알 필요 없이 요청된 서비스를 이용한다. 클라이언트/서버 아키텍처에서, 특히 네트워크 시스템에서, 클라이언트는 일반적으로 다른 컴퓨터, 즉, 서버에 의해 제공되는 공유된 네트워크 자원을 접근하는 컴퓨터이다. 비록 상황에 따라서, 어느 컴퓨터도 클라이언트, 서버, 또는 둘 다 겸한 것으로 간주할 수 있지만, 도 16의 예에서, 컴퓨터(110a, 110b, 등)는 클라이언트로 생각할 수 있고, 컴퓨터(10a, 10b, 등)는 서버로 생각할 수 있다. 이런 컴퓨팅 장치의 어느 것이든 본 발명의 객체 보존 기술을 내포한 방식으로 데이터를 처리할 수 있다.

서버는 전형적으로 인터넷과 같은 원격 또는 로컬 네트워크를 걸쳐 접근 가능한 원격 컴퓨터 시스템이다. 클라이언트 프로세스는 첫번째 컴퓨터에서 활동하고, 서버 프로세스는 두번째 컴퓨터에서 활동하고, 통신 매체를 통해 다른 쪽과 통신함으로써, 분산 기능을 제공하고 다수의 클라이언트 서버의 정보 수집 재능의 이점을 취하도록 허용한다. 본 발명의 보존 메커니즘을 따라 이용되는 어느 소프트웨어 객체도 다수의 컴퓨팅 장치를 걸쳐 분산될 수 있다.

클라이언트와 서버는 프로토콜 계층에서 제공하는 기능을 이용하여 서로 통신한다. 예를 들어, 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol, HTTP)은 월드 와이드 웹(World Wide Web, WWW), 또는 웹(Web)과 함께 사용되는 공통 프로토콜이다. 전형적으로, 인터넷 프로토콜(Internet Protocol, IP)과 같은 컴퓨터 네트워크 주소나 유니버설 리소스 로케이터(Universal Resource Locator, URL)와 같은 다른 참조는 서버 또는 클라이언트 컴퓨터를 서로 식별하기 위해 사용된다. 네트워크 주소는 URL주소로도 일컫는다. 통신은 임의의 사용 가능한 통신 매체를 통해 제공된다.

도 16은 서버가 네트워크/버스를 통해 클라이언트 컴퓨터와 통신하며, 본 발명이 이용될 수 있는 예시적인 네트워크 또는 분산 환경을 나타내고 있다. 네트워크/버스(14)는 LAN, WAN, 인트라넷, 인터넷, 또는 다수의 클라이언트 혹은 휴대형 컴퓨터, 핸드헬드 컴퓨터, 씬(thin) 클라이언트, 네트워크 가전제품, 혹은 VCR, TV, 오븐(oven), 전등, 히터(heater) 및 본 발명과 일치하는 것과 같은 원격 컴퓨팅 장치(110a, 110b, 110c, 110d, 110e, 등)가 있는 다른 네트워크 매체일 수 있다. 이와 같이 본 발명은 보존된 객체를 유지하기에 바람직함에 관련된 어느 컴퓨팅 장치에도 적용된다는 것을 심사숙고했다.

통신 네트워크/버스(14)가 인터넷인 네트워크 환경에서, 예를 들어, 서버(10a, 10b, 등)는 클라이언트(110a, 110b, 110c, 110d, 110e, 등)가 HTTP와 같은 다수의 알려진 프로토콜 중 임의의 것을 통해 통신하는 서버일 수 있다. 서버(10a, 10b, 등)는 분산 컴퓨팅 환경의 특징일 수 있는 클라이언트(110a, 110b, 110c, 110d, 110e, 등)와 같은 역할도 한다.

통신은 적절하게 유선 또는 무선일 수 있다. 클라이언트 장치(110a, 110b, 110c, 110d, 110e, 등)는 통신 네트워크/버스(14)를 통해 통신할 수도 있고 통신하기 않을 수도 있고, 관련된 독립 통신을 갖출 수 있다. 예를 들어, TV 또는 VCR의 경우, 제어에 대하여 네트워크화된 부분이 있을 수도 있고 없을 수도 있다. 각 클라이언트 컴퓨터(110a, 110b, 110c, 110d, 110e, 등)와 서버 컴퓨터(10a, 10b, 등)에는 각종 응용 프로그램 모듈 또는 객체(135)와, 다양한 타입의 저장 요소 또는 객체에 대한 연결 또는 접근이 제공될 수 있으며, 그를 통하여 파일 또는 데이터 스트림이 저장될 수 있고, 파일 또는 데이터 스트림의 부분이 거기에 다운로드, 전송, 이동될 수 있다. 어느 컴퓨터(10a, 10b, 110a, 110b, 등등)든 데이터베이스, 메모리, 또는 본 발명과 일치하여 처리된 데이터를 저장하는 다른 저장 요소(20)의 유지와 갱신을 책임진다. 그러므로, 본 발명은 컴퓨터 네트워크/버스(14)에 접근하여 상호 작용하는 클라이언트 컴퓨터(110a, 110b, 등)와 클라이언트 컴퓨터(110a, 110b, 등) 및 다른 동등한 장치와 상호 작용하는 서버 컴퓨터(10a, 10b, 등)와 데이터베이스(20)을 갖춘 컴퓨터 네트워크 환경에 이용된다.

도 17과 다음 논의가 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경의 간략하고 전반적인 설명을 제공할 것이다. 예를 들어, 도 16에 설명한 어느 클라이언트와 서버 컴퓨터 또는 장치든 이런 형태를 취한다. 그러나, 핸드헬드, 포터블, 및 모든 종류의 다른 컴퓨팅 장치 및 컴퓨팅 객체가 본 발명에 관련되어 사용될 것으로 예상된다는 것은 이해되어야 한다. 즉, 본 발명은 컴퓨팅 환경 내에서 데이터가 발생, 처리, 수신 및/혹은 전송될 수 있는 모든 곳에서 이용된다. 비록 다음에 범용 컴퓨터가 언급되지만, 이것은 단지 하나의 예시일 뿐이고, 본 발명은 네트워크/버스 상호동작성(interoperability)과 상호 작용을 갖춘 씬(thin) 클라이언트와 함께 구현될 수 있다. 그러므로, 본 발명은 아주 거의 없는 또는 최소한의 클 라이언트 자원을 포함하는 네트워크 호스팅 서비스(networked hosted services) 환경에서 구현될 수 있다. 예를 들면, 클라이언트 장치는 그저 가전 제품에 설치된 객체 같은 네트워크/버스의 인터페이스처럼 기능하는 네트워크 환경이다. 본질적으로, 데이터가 저장되고 또는 검색되고 혹은 다른 컴퓨터에 전송되는 어느 곳이든 본 발명의 객체 보존 방법 태스크에 바람직하고 적합한 환경이다.

비록 요구되는 것은 아니지만, 본 발명은 운용 시스템을 통해서, 장치 또는 객체의 서비스 개발자에 의해 사용되도록 구현될 수 있고, 그리고/또는 본 발명에 따라 작용하는 응용 프로그램 또는 서버 소프트웨어에 포함될 수 있다. 소프트웨어는 프로그램 모듈과 같고 하나 이상의 클라이언트 워크스테이션, 서버 또는 다른 장치와 같은 컴퓨터에서 실행되는 컴퓨터 실행가능 명령문의 일반 콘텍스트로 서술된다. 일반적으로 프로그램 모듈은 특유의 태스크를 이행하는 혹은 특유의 추상적인 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조와 같은 것을 포함한다. 전형적으로, 프로그램 모듈의 기능성은 다양한 실시예에서 요구되는 바와 같이 결합되거나 분산된다. 더구나, 본 발명은 다른 컴퓨터 시스템 구조와 프로토콜과 함께 실시된다. 본 발명이 사용되기에 적합한 다른 공지된 컴퓨팅 시스템, 환경, 및/혹은 구성은, 개인 컴퓨터, 현금 자동 입출금기, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 다중 프로세서 시스템, 마이크로 프로세서 기반의 시스템, 프로그램 가능한 소비자 전자 제품, 네트워크 PC, 가전 제품, 전등, 환경 제어 요소, 미니 컴퓨터, 메인 프레임 컴퓨터와 같은 것을 포함하나, 이에 제한되지 않는다.

도 17은 본 발명이 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 한 예를 보여준다. 비록 앞에서 명확하게 했으나, 컴퓨팅 환경(100)은 단지 적합한 컴퓨팅 환경의 한 예이며, 본 발명의 사용 범위 또는 기능성에 그 어떤 제한을 가하자는 것이 아니다. 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에서 보여준 어는 하나의 혹은 결합된 컴포넌트와 관련되는 의존성 또는 필요성으로 해석되어서는 안 된다.

도 17에서, 본 발명을 구현하는 예시적인 시스템은 컴퓨터(110) 구조의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 구성은 프로세싱 장치(120), 시스템 메모리(130), 및 시스템 메모리를 포함하여 각종 시스템 컴포넌트를 프로세싱 장치(120)에 연결시키는 시스템 버스(121)를 포함하지만, 이에 제한되지 않는다. 시스템 버스(121)는 다양한 버스 아키텍처를 사용하는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 및 로컬 버스를 포함한 몇가지 타입의 버스 구조중 어느 한 가지일 수 있다. 한 예로서, 이러한 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 버스, PCI(Peripheral Component Interconnect) 버스 (또는 Mezzanine 버스라고도 함)를 포함하나, 이에 제한되지 않는다.

컴퓨터(110)는 전형적으로 다양한 컴퓨터 판독 가능 매체를 포함한다. 컴퓨터 판독 가능 매체는 컴퓨터(110)가 액세스할 수 있는 사용 가능한 어떤 매체일 수도 있으며, 그리고 휘발성 및 비휘발성 매체, 분리가능한 및 분리불가능한 매체를 포함한다. 한 예로서, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수도 있으나, 이에 제한되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈, 또는 기타 데이터와 같은 정보의 어떤 저장 방법 또는 임의의 기술로 구현되는 휘발성 및 비휘발성, 분리가능한 및 분리불가능한 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 기술의 메모리, CDROM, DVD(digital versatile disk), 또는 기타 광 디스크 저장 매체, 자기 카세트, 자기 테이프, 자기 디스크 저장 매체 또는 기타 자기 저장 매체, 또는 원하는 정보를 저장하는데 사용할 수 있으며, 컴퓨터(110)가 액세스할 수 있는 기타 매체를 포함하나, 이에 제한되지 않는다. 통신 매체는 전형적으로 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파 같은 변조된 데이터 시그널(modulated data signal) 혹은 다른 전송 메커니즘으로 구체화하고, 임의의 정보 전송 매체도 포함한다. 상기 변조된 데이터 시그널은 정보를 신호에 암호화하는 방식으로 설정 또는 변경된 하나 이상의 특징을 갖는 신호를 의미한다. 한 예로서, 통신 매체는 유선 네트워크 혹은 직접연결(direct-wired connection) 같은 유선 매체와 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하나, 이에 제한되지 않는다. 또한 상기 매체의 어떤 조합도 컴퓨터 판독 가능 매체 범위에 포함되어야 한다.

시스템 메모리(130)는 ROM(131)(read only memory)과 RAM(132)(random access memory)과 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. BIOS(133)(basic input/output system)는 컴퓨터(110)가 시동 하는 동안 구성 요소들 사이의 정보의 전송을 돕는 기본 루틴을 포함하는데 일반적으로 ROM(131)에 저장된다. RAM(132)은 정형적으로 프로세싱 장치(120)에 의해 즉시 액세스 가능하고 및/또는 조작되는 데이터 및/또는 프로그램 모듈을 포함한다. 한 예로서, 도 17은 운영 시스템(134), 응용프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.

또한 컴퓨터(110)는 기타 분리가능한/분리불가능한, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수도 있다. 단지 예로서, 도 8은 분리불가능한 비휘발성 자기 매체에 판독하거나 기록할 수 있는 하드 디스크 드라이브(141), 분리가능한 비휘발성 자기 디스크(152)에 판독하거나 기록할 수 있는 자기 디스크 드라이브(151)와 CD-RW, DVD-RW 또는 다른 광학 매체와 같은 분리가능한, 비휘발성 광 디스크(156)에 판독하거나 기록할 수 있는 광 디스크 드라이브(155)를 보여준다. 본 예시적인 운영 환경에서 사용할 수 있는 기타 분리가능한/분리불가능한, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, 디지털 다기능 디스크, 디지털 비디오 테이프, 고체 RAM, 고체 ROM 및 같은 종류를 포함하나, 이에 제한되지 않는다. 하드 디스크 드라이브(141)는 정형적으로 인터페이스(140)와 같은 분리불가능한 메모리 인터페이스를 통해 시스템 버스(121)에 연결 돼 있고, 자기 디스크 드라이브(151)와 광 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리가능한 메모리 인터페이스로 시스템 버스(121)에 연결 되어 있다.

앞에서 논의하고, 또한 도 17에서 도시된 드라이브와 관련된 컴퓨터 저장 매체는 컴퓨터(110)에게 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장 장소를 제공한다. 예로, 도 17에서 하드 디스크 드라이브(141)는 운영 시스템(144), 응용 프로그램(145), 기타 프로그램 모듈(146)과 프로그램 데이터(147)를 저장한 것을 도시한다. 이런 컴포넌트는 운영 시스템(134), 응용 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 같거나 상이할 수 있다는 것을 주의하자. 적어도 그것들은 다른 복사본이라는 것을 보여주기 위해 여기서 운영 시스템(144), 응용 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)에 다른 번호가 주어진 것이다. 사용자는 키보드(162) 같은 입력 장치와 마우스(mouse), 트랙 볼(trackball), 또는 터치 패드(touch pad)와 같은 포인팅 디바이스(161)를 통해 컴퓨터(110)에 커맨드과 정보를 입력할 수 있다. 기타 입력 장치(도시되지 않음)는 마이크로 폰(microphone), 조이스틱(joystick), 게임 패드(game pad), 인공위성 접시(satellite dish), 스캐너(scanner) 또는 같은 것을 포함할 수도 있다. 이들과 다른 입력 장치는 종종 시스템 버스(121)에 연결된 사용자 입력 인터페이스(160)를 통해 프로세싱(processing) 장치(120)와 연결 되어 있지만, 다른 인터페이스와 병렬 포트(parallel port), 게임 포트(game port), 혹은 USB(universal serial bus)와 같은 버스 구조에 의해 연결될 수도 있다. 그래픽 인터페이스(182)도 시스템 버스(121)에 연결될 수도 있다. 하나 이상의 GPU(graphic processing unit) 장치(184)는 그래픽 인터페이스(182)와 통신할 수도 있다. 모니터(191) 또는 다른 타입의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 거쳐 시스템 버스(121)에 연결 되어있는데, 그 인터페이스는 비디오 메모리(186)와 번갈아 통신할 수 있다. 모니터 (191) 외에, 컴퓨터는 스피커(197)와 프린터(196)와 같은 다른 출력 주변 장치를 포함하는데, 그것은 출력 주변 인터페이스(195)를 거쳐 연결될 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원견 컴퓨터에 논리적 연결을 이용한 네트워킹 또는 분산 환경에서 작용할 수 있다. 원격 컴퓨터(180)는 개인 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer)장치 또는 다른 공용 네트워크 노드(node)일수도 있고, 비록 도 17에서 메모리 저장 장치(181)만 도시했으나, 전형적으로 컴퓨터(110)에 관해 위에 언급한 여러 혹은 모든 요소를 포함한다. 도 17에서 묘사한 논리적 연결은 LAN(171)과 WAN(173)을 포함한다. 그러나 다른 네트워크/버스도 포함할 수 있다. 이러한 네트워킹 환경은 사무실, 기업체 전반 컴퓨터 네트워크, 인트라넷 및 인터넷에서 보편적으로 존재한다.

LAN 네트워킹 환경에서 사용할 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 연결된다. WAN 네트워킹 환경에서 사용할 경우, 컴퓨터(110)는 전형적으로 모뎀(172) 혹은 인터넷과 같은 WAN(173) 상에서 통신을 설립하는 다른 수단을 포함한다. 내장 또는 외장형 일수도 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적당한 메커니즘을 통해 시스템 버스(121)에 연결될 수 있다. 네트워킹 환경에서, 컴퓨터(110)에 관해 서술된 프로그램 모듈 혹은 그것의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 제한을 두지 않는 예로서, 도 17에서 메모리 장치(181)에 상주하는 원격 응용 프로그램(185)을 도시한다. 도시된 네트워크 연결은 범례로 인식될 것이며, 그리고 컴퓨터간 통신 연결을 설립하는 다른 수단이 이용될 수도 있다.

상술된 바와 같이, 본 발명은 데이터베이스 저장소 내에서 사용자 정의 타입의 인스턴스의 필드로서 XML 데이터를 저장 및 검색하기 위한 시스템 및 방법에 관한 것이다. 본 발명의 포괄적인 개념으로부터 벗어나지 않고서 상술된 실시예에 대해 변경을 행할 수 있음을 이해해야 한다. 예를 들어, 본 발명의 실시예는 마이크로소프트의 SQL SERVER 데이터베이스 관리 시스템에서 구현되는 것으로서 상술되었지만, 본 발명은 사용자 정의 타입의 생성을 지원하는 임의의 데이터베이스 관리 시스템에서 구현될 수 있다. 따라서, 본 발명은 개시된 특정 실시예로 제한되지 않으며, 첨부 청구범위에 의해 정의된 본 발명의 취지 및 범주 내에 있는 모든 변경을 포함하는 것으로 의도된다.

Claims

사용자 정의 타입(user defined type)이 관리되는 코드(managed code)의 클래스에 의해 정의되고 복수 개의 필드를 포함하는, 데이터베이스 시스템에서의 사용을 위한 방법으로서 - 상기 필드 각각은 각각의 데이터 타입을 가짐 -,

XML 데이터 타입을 나타내는 관리되는 코드의 다른 클래스를 정의하는 단계;

상기 XML 데이터 타입을 갖도록 상기 사용자 정의 타입의 상기 복수 개의 필드 중 모두가 아닌 적어도 하나를 정의하고, 상기 사용자 정의 타입의 인스턴스의 적어도 하나의 필드를 해당 필드 내의 상기 XML 데이터에 대한 컨텐츠 모델을 정의하는 XML 스키마에 연계시키며, 상이한 데이터 타입을 갖도록 상기 복수 개의 필드 중 적어도 다른 하나를 정의하는 단계;

사용자에 의해 정의된 적어도 하나의 사용자 특정 비-XML 데이터 구성자(user specific non-XML data constructor), 적어도 하나의 XML 데이터 구성자, 및 XML 인터페이스 객체를 포함하는 상기 사용자 정의 타입의 객체를 생성하기 위해 상기 사용자 정의 타입을 정의하는 상기 클래스를 인스턴스화(instantiate)하는 단계 - 상기 객체는 적어도 하나의 필드 내에 XML 데이터를 보유하고, 상기 적어도 다른 하나의 필드 내에 상이한 데이터 타입의 데이터를 보유함 - ;

데이터베이스 저장소 내에 상기 객체를 보존하는 단계; 및

비-XML 데이터를 스트림에 기록하고 상기 스트림에서 상기 XML 인터페이스 객체를 인스턴스화하여 XML 데이터 및 비-XML 데이터 양자를 스트림 또는 파일에 기록하는 단계

를 포함하는 데이터베이스 시스템에서의 사용을 위한 방법.
제1항에 있어서,

상기 XML 데이터 타입을 나타내는 상기 관리되는 코드의 클래스는 적어도 하나의 구성자, 및 상기 사용자 정의 타입의 상기 보존된 객체의 상기 적어도 하나의 필드 내의 상기 XML 데이터가 검색될 수 있게 하는 객체를 리턴하는 적어도 하나의 메소드를 포함하는, 데이터베이스 시스템에서의 사용을 위한 방법.
제1항에 있어서,

상기 사용자 정의 타입의 상기 적어도 하나의 필드에 대한 동작(behavior)을 구현하기 위한 메소드를 상기 사용자 정의 타입의 상기 관리되는 코드의 클래스 정의에 추가하는 단계를 더 포함하는, 데이터베이스 시스템에서의 사용을 위한 방법.
삭제
제1항에 있어서,

상기 연계시키는 것은 상기 사용자 정의 타입의 상기 관리되는 코드의 클래스 정의를 상기 데이터베이스 저장소를 호스트하는 서버 상의 XML 스키마를 식별하는 속성으로 주석(annotating)하는 것을 포함하는, 데이터베이스 시스템에서의 사용을 위한 방법.
제1항에 있어서,

상기 데이터베이스 저장소 내에 보존된 상기 객체를 쿼리하는(querying) 단계; 및

상기 데이터베이스 저장소 내에 보존된 상기 객체를 변경하는 단계

중 적어도 하나를 더 포함하는, 데이터베이스 시스템에서의 사용을 위한 방법.
시스템으로서,

관리되는 코드 실행을 제공하는 런타임(runtime)

- 상기 런타임은,

XML 데이터 타입을 나타내는 관리되는 코드의 클래스, 및

사용자 정의 타입을 정의하는 관리되는 코드의 다른 클래스 - 상기 사용자 정의 타입에 대한 클래스 정의는 복수 개의 필드를 포함하고, 상기 필드 각각은 상기 XML 데이터 타입을 가지며, 상기 복수 개의 필드들 중 적어도 다른 하나는 상이한 데이터 타입을 갖도록 정의되고, 사용자에 의해 정의된 적어도 하나의 사용자 특정 비-XML 데이터 구성자, 적어도 하나의 XML 데이터 구성자, 및 XML 인터페이스 객체를 포함하는 상기 사용자 정의 타입을 정의하는 상기 관리되는 코드의 클래스는, XML 데이터를 포함하는 상기 사용자 정의 타입의 인스턴스의 적어도 하나의 필드와, 해당 필드 내의 상기 XML 데이터에 대한 컨텐츠 모델을 정의하는 XML 스키마 간의 연계를 더 포함함 -

를 포함함 - ;

상기 사용자 정의 타입의 객체를 생성하기 위해 상기 사용자 정의 타입을 정의하는 상기 클래스를 인스턴스화하고 상기 객체를 저장하는 데이터베이스 저장소 - 상기 저장된 객체의 적어도 하나의 필드는 XML 데이터를 포함하고 상기 객체의 적어도 다른 하나의 필드는 상기 상이한 데이터 타입의 데이터를 포함함 - ; 및

비-XML 데이터를 스트림에 기록하고 상기 스트림에서 상기 XML 인터페이스 객체를 인스턴스화하여 XML 데이터 및 비-XML 데이터 양자를 스트림 또는 파일에 기록하는 통신 객체

를 포함하는 시스템.
제7항에 있어서,

상기 XML 데이터 타입을 나타내는 상기 관리되는 코드의 클래스는 적어도 하나의 구성자, 및 상기 사용자 정의 타입의 상기 저장된 객체의 필드 내의 상기 XML 데이터가 검색될 수 있게 하는 객체를 리턴하는 적어도 하나의 메소드를 포함하는 시스템.
제7항에 있어서,

상기 사용자 정의 타입을 정의하는 상기 관리되는 코드의 클래스는 XML 데이터를 포함하는 상기 사용자 정의 타입의 인스턴스의 필드에 대한 동작을 구현하는 메소드를 더 포함하는 시스템.
삭제
제7항에 있어서,

상기 연계는 상기 사용자 정의 타입을 정의하는 상기 관리되는 코드의 클래스 내의 필드에 적용되는 속성을 포함하고, 상기 속성은 상기 데이터베이스 저장소를 호스트하는 서버 상의 XML 스키마를 식별하는 시스템.
사용자 정의 타입의 인스턴스인 객체가 데이터베이스 저장소에 보존될 수 있는 시스템에서의 실행을 위한 컴퓨터 실행가능 명령어가 저장되어 있는 컴퓨터 판독가능 저장 매체로서, 상기 컴퓨터 실행가능 명령어는, 상기 시스템 내의 프로세서에 의해 실행될 때,

XML 데이터 타입을 나타내는 관리되는 코드의 제1 클래스를 정의하는 단계;

사용자 정의 타입을 정의하는 관리되는 코드의 제2 클래스를 정의하는 단계 - 상기 제2 클래스는 복수 개의 필드를 포함하고, 상기 필드 각각은 각각의 데이터 타입을 갖고, 상기 제2 클래스 내의 필드들 중 모두가 아닌 적어도 하나의 필드는 상기 XML 데이터 타입을 갖도록 정의되고, 해당 필드 내의 상기 XML 데이터에 대한 컨텐츠 모델을 정의하는 XML 스키마에 연계되며, 상기 복수 개의 필드 중 적어도 다른 하나는 상이한 데이터 타입을 갖도록 정의됨 - ;

사용자에 의해 정의된 적어도 하나의 사용자 특정 비-XML 데이터 구성자(user specific non-XML data constructor), 적어도 하나의 XML 데이터 구성자, 및 XML 인터페이스 객체를 포함하는 상기 사용자 정의 타입의 객체를 생성하기 위해 상기 사용자 정의 타입을 정의하는 상기 제2 클래스를 인스턴스화하는 단계 - 상기 객체의 적어도 하나의 필드는 XML 데이터를 보유하고 상기 객체의 적어도 다른 하나의 필드는 상기 상이한 데이터 타입의 데이터를 보유함 - ;

데이터베이스 저장소 내에 상기 객체를 보존하는 단계; 및

비-XML 데이터를 스트림에 기록하고 상기 스트림의 상기 XML 인터페이스 객체를 인스턴스화하여 XML 데이터 및 비-XML 데이터 양자를 스트림 또는 파일에 기록하는 단계

를 포함하는 방법을 구현하는, 컴퓨터 판독가능 저장 매체.
제12항에 있어서,

상기 제1 클래스는 적어도 하나의 구성자, 및 상기 사용자 정의 타입의 상기 보존된 객체의 필드 내의 XML 데이터가 검색될 수 있게 하는 객체를 리턴하는 적어도 하나의 메소드를 포함하는 컴퓨터 판독가능 저장 매체.
제12항에 있어서,

상기 제2 클래스는 상기 사용자 정의 타입의 상기 적어도 하나의 필드에 대한 동작을 구현하는 메소드를 더 포함하는 컴퓨터 판독가능 저장 매체.
삭제
제12항에 있어서,

상기 적어도 하나의 필드는, 제2 클래스 내의 상기 적어도 하나의 필드의 정의에 대하여 상기 데이터베이스 저장소를 호스트하는 서버 상의 상기 XML 스키마를 식별하는 속성으로 주석하는 것에 의해, 상기 XML 스키마에 연계되는 컴퓨터 판독가능 저장 매체.
제12항에 있어서,

상기 컴퓨터 실행가능 명령어는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금,

상기 데이터베이스 저장소 내에 보존된 상기 객체를 쿼리하고;

상기 데이터베이스 저장소 내에 보존된 상기 객체를 변경할 수 있게 하는 컴퓨터 판독가능 저장 매체.