KR101030368B1 - 데이터 저장소 내의 비순서화 및 순서화 컬렉션의 구현을 위한 시스템 및 방법 - Google Patents

Abstract

본 발명의 몇몇 실시예는 비순서화된 컬렉션(멀티세트) 및 순서화된 컬렉션(리스트)을 위한 지원을 포함하도록 확장된 관계형 데이터 저장소(ERDS)의 UDT 프레임워크를 확장하는 시스템 및 방법에 관한 것이다. 더욱 구체적으로, 본 발명의 몇몇 실시예는 동시에 스칼라 및 관계형인 컬렉션에 대한 특정 타입 추상화를 작성하여 이용하기 위해 UDT 기반구조, CLR 제너릭 및 새로운 UNNEST 연산자를 사용한다. 스칼라로서, 이 컬렉션 타입은 스칼라를 이해하는 데이터 저장소 엔진의 모든 부분(클라이언트 스택을 포함하지만 이에 제한되지 않음)에 의해 프로세스될 수 있고, 관계형으로서, 이 컬렉션 타입은 임의의 다른 관계형과 같이 조회가능하다.

컬렉션, 스칼라, 관계형, 사용자 정의 타입, CLR, SQL, UNNEST 연산자

Description

데이터 저장소 내의 비순서화 및 순서화 컬렉션의 구현을 위한 시스템 및 방법{SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF UNORDERED AND ORDERED COLLECTIONS IN A DATA STORE}

도 1은 본 발명의 실시양상이 사용될 수 있는 컴퓨터 시스템을 도시한 블록도.

도 2는 관리 코드 내에 인스턴스화되어 있는 사용자 정의 타입의 인스턴스의 직렬화 및 역직렬화를 도시한 블록도.

도 3은 확장가능 관계형 데이터 저장소(ERDS)가 이원적(스칼라 및 관계형) 컬렉션 타입을 제공할 수 있게 하는 일반적 방법을 도시한 프로세스 흐름도.

도 4는 엔티티 내의 컬렉션에 적용된 조회를 프로세스하는 일반적 방법을 도시한 프로세스 흐름도.

도 5는 조회시, 조회가능 객체 내로 언네스트(unnest)되는 임베디드(embedded) 필드로서 멀티세트(multiset)를 갖는 구조적 UDT인 엔티티를 도시한 블록도.

도 6은 멀티세트 대신에 리스트에 대해 언네스트되는 도 5로부터의 조회가능 객체를 도시한 부분 블록도.

<도면의 주요 부분에 대한 부호의 설명>

20 : 컴퓨터

22 : 시스템 메모리

49 : 원격 컴퓨터

62 : 저장 장치

500 : Person 엔티티

510 : 임베디드 필드

510', 510" : 조회가능 객체

[문헌 1] USA 60/566,740 "Systems and Methods for the Implementation of Multisets in a Database System" 2004.04.30 (Atty.Docket No. MSFT-3940/307228.01)

[문헌 2] USA 10/775,282 "System and Method for Providing User Defined Types in a Database System" 2004.02.10 (Atty.Docket No. MSFT-3029/307007.01)

[문헌 3] USA 10/837,929 "Systems and Methods for Supporting Inheritance for User-Defined Types" 2004.05.03 (Atty.Docket No. MSFT-3843/307227.01)

[문헌 4] USA 10/821,687 "System and Method for Fragment-Based Serialization" 2004.04.09 (Atty.Docket No. MSFT-2955/307064.01)

[문헌 5] USA 10/692,225 "System and Method for Object Persistence in a Database Store" 2003.10.23 (Atty.Docket No. MSFT-2852/306819.01)

[문헌 6] USA 10/795,623 "Structured Indexes on Result of Function Application over Data" 2004.03.08 (Atty.Docket No. MSFT-2960/307232.01)

본 발명은 컴퓨터 시스템 내의 데이터 저장장치, 및 데이터베이스 시스템 내의 사용자 정의 타입(UDT)을 지원하는 시스템에 관한 것으로, 여기서, UDT는 관계형 데이터베이스 엔진 및 파일 시스템과 관련하여 채용되어, 특정 약정을 구현하는 관리 타입을 등록함으로써 데이터 저장소의 스칼라 타입 시스템(들)을 확장하기 위한 확장성 메카니즘이다. 더욱 구체적으로, 본 발명은 스칼라이고 조회가능한 UDT를 통한 데이터베이스 시스템 내의 멀티세트 및 순서화된 컬렉션의 구현에 관한 것이다.

사용자 정의 타입

본 분야에 숙련된 기술자들에게 공지되고 인식된 바와 같이, MICROSOFT SQL SERVER는 확장 관리 및 개발 툴, 추출-변환-로딩(ETL) 툴, 비즈니스 지능 및 분석 서비스 및 기타 기능들을 제공하는 포괄적인 데이터베이스 관리 플랫폼이다. 게다가, 최근에 이 SQL SERVER 데이터베이스에 MICROSOFT WINDOWS.NET 프레임워크 공통 언어 런타임(Framework Common Language Runtime(CLR))이 통합되었다.

CLR은 MICROSOFT.NET 프레임워크의 핵심이며, 모든 .NET 코드를 위한 실행 환경을 제공한다. CLR 내에서 실행되는 코드는 "관리 코드(managed code)"로 칭해진다. CLR은 JIT(just-in-time) 컴파일, 메모리 할당 및 관리, 타입 안전 시행, 예외 처리, 스레드 관리 및 보안을 포함하여 프로그램 실행에 필요한 다양한 기능 및 서비스를 제공한다. 현재에는, CLR은 .NET 루틴의 첫번째 호출 시에 SQL SERVER에 의해 로드된다.

SQL SERVER의 이전 버전에서, 데이터베이스 프로그래머는 서버측 상에서 코드를 작성(write)할 때 Transact-SQL을 사용하도록 제약을 받았다. Transact-SQL은 ISO(International Standard Organization) 및 ANSI(American National Standards Institute)에 의해 정의된 바와 같은 구조화 조회 언어(Structured Query Language: SQL)의 연장이다. Transact-SQL을 사용하여, 데이베이스 개발자는 데이터베이스 내에 저장된 데이터를 삽입, 검색, 변경 및 삭제할 뿐만 아니라, 데이터베이스 및 테이블을 생성, 변경 및 삭제할 수 있다. Transact-SQL은 직접 구조 데이터 액세스 및 조작을 위해 특별히 설계된다. Transact-SQL은 구조 데이터 액세스 및 관리가 뛰어나지만, VISUAL BASIC.NET 및 C#과 같이 완전 독립형(full-fledged) 프로그래밍 언어는 아니다. 예를 들어, Transact-SQL은 어레이, 컬렉션, 각각의 루프, 비트 시프팅, 또는 클래스를 지원하지 못한다.

CLR이 SQL SERVER 데이터베이스 내로 통합됨에 따라, 데이터베이스 개발자들은 Transact-SQL만으로 달성하기 어렵거나 불가능했던 태스크들을 실행할 수 있었다. VISUAL BASIC.NET 및 C#은 어레이, 구조적 예외 처리 및 컬렉션에 충분한 지원을 제공하는 최신 프로그래밍 언어이다. 개발자들은 CLR 통합을 도입하여, VISUAL BASIC.NET 및 C#과 같은 언어를 사용하여 계산 태스크에 더욱 적합하게 되고 더욱 복잡한 로직을 갖는 코드를 효과적으로 작성할 수 있다. 이들 프로그래밍 언어는 요약화(encapsulation), 상속(inheritance) 및 다형성(polymorphism)과 같은 객체 지향 기능을 제공한다. 관련된 코드는 클래스 및 네임스페이스(namespace)로 쉽게 조직될 수 있다.

관리 코드는 Transact-SQL보다도 수치 처리 및 복잡한 실행 로직에 더욱 적합하고, 스트링 처리 및 정규 표현식을 포함하는 많은 복잡한 태스크에 대한 확장 지원을 특징화 한다. .NET 프레임워크 베이스 클래스 라이브러리(Framework Base Class Library(BCL))에서 찾을 수 있는 기능을 이용하여, 데이터베이스 개발자는 임의의 저장된 절차, 트리거 또는 사용자 정의 함수로부터 쉽게 액세스될 수 있는 수천의 사전-작성된 클래스 및 루틴에 액세스한다.

관리 코드의 다른 이점은 타입 안전성이다. 관리 코드가 실행되기 전에, CLR은 코드가 안전하다는 것을 검증한다. 이 프로세스는 "검증"으로 알려져 있다. 검증 동안에, CLR은 코드가 실행하기에 안전하다는 것을 보장하기 위해 몇 가지 검사를 실행한다. 예를 들어, 코드는 기입되어 있지 않은 메모리를 판독하지는 않는 것을 보장하기 위해 검사된다. CLR은 또한 버퍼 오버플로우를 방지할 수 있을 것이다.

관리 코드를 작성할 때, 배치 단위(deployment unit)를 어셈블리라 칭한다. 어셈블리는 동적 연결 라이브러리(dynamic link library: DLL)로서 패키지된다. 관리형 DLL 어셈블리는 SQL SERVER 내로 로드되어 그 SQL SERVER에 의해 호스트될 수 있다. CREATE ASSEMBLY 문장은 서버 내에 어셈블리를 등록하기 위해 사용된다. 한 예는 다음과 같다:

CREATE ASSEMBLY YukonCLR

FROM 'C:＼MyDBApp＼YukonCLR.dll'

이 예에서, FROM 절은 로드하기 위한 어셈블리의 경로명을 지정한다.

SQL SERVER는 통상 정수, 부동 소수점 수, 날짜, 시간, 및 문자열과 같은 "기본 제공형(built-in)" 스칼라 타입을 지원했다. 이들 기본 제공형은 또한 이들 타입에 관한 내장 함수뿐만 아니라 +,-,*,/와 같은 내장 연산 집합이 딸려 있다. 이들 타입, 연산 및 함수는 구현되어 제품으로 패키지되고 사용자가 그들 자신의 타입을 정의할 수 없다는 점에서 "기본 제공형"이다.

SQL SERVER와 같은 데이터베이스 시스템은 사용자에게 데이터베이스 시스템의 타입 시스템을 확장할 수 있게 하도록 하여, 사용자가 데이터베이스 시스템 내에서 스칼라 타입으로서 작용하지만, 보다 복잡한 구조 및 행위를 포함하는 새로운 타입을 작성할 수 있도록 하는 것이 바람직한데, 그 중에서도 특히, X 및 Y 좌표로 이루어진 "포인트(Point)" 타입을 작성하는 것이 바람직하다. 이와 관련하여, SQL 표준 및 소정의 데이터베이스 관리 시스템(DBMS) 제품은 타입 확장성의 몇 가지 폼을 기술(describe)하기 위해 "사용자 정의 타입"이란 용어를 사용해 왔다. 예를 들어, SQL-99 표준은 기존의 SQL 기본제공형 데이터형의 값인 내부 표현을 갖도록 사용자에 의해 정의될 수 있는 한 타입인 "디스팅트 타입(distinct type)"을 설명한다. 디스팅트 타입은 비교 및 산술 연산자, 타입 변환, 및 집합(열) 함수(예를 들어, 최대, 최소, 평균)를 현존하는 스칼라 타입과 선택적으로 공유할 수 있다. 디스팅트 타입은 제약들(constraints)이 그 값에 관해서 정의될 수 있게 할 수 있 다. 게다가, 디스팅트 타입은 사용자 정의 함수를 통해 디스팅트 타입에 특정된 새로운 함수를 정의함으로써 현존하는 스칼라 타입의 행위들보다도 더욱 행위들을 노출시킬 수 있다. 타입 검사에 관하여, 디스팅트 타입 및 현존하는 스칼라 타입은 서로 다른 타입으로 간주된다.

디스팅트 타입의 장점은 정의의 용이함이다. 새로운 타입의 내부 표현이 현존하는 내장형으로 설명될 수 있는 단일 데이터 멤버를 갖고 있고, 내장형이 새로운 타입에 필요한 대부분의 행위를 이미 구현한다면, 디스팅트 타입은 매력적인 대안이다. 사용자는 타입, 구성자, 비교 연산자(순서화 및 인덱스화에 사용됨), 산술 연산자 및 타입 변환(캐스팅) 연산자의 온-디스크 저장을 관리하기 위해 필요한 행위의 구현에 대해 걱정할 필요가 없다. 사용자는 단지, 기본 제공형의 어떤 기능이 디스팅트 타입에 관해 노출될 필요가 있는 가를 선택하고, 새로운 타입에 관한 값 또는 추가 함수에 대한 제약을 선택적으로 추가할 필요가 있다. 디스팅트 타입의 다른 장점은 히스토그램의 계산과 같이 기본 제공형에 이용가능한 모든 조회 프로세싱이 디스팅트 타입의 열(column)에서 용이하게 사용될 수 있다는 것이다. 그러나, 디스팅트 타입의 단점은 더욱 복잡한 타입을 작성하는 데에는 쉽게 사용될 수 없다는 것이다.

SQL-99 표준은 또한, 사용자에 의해 정의될 수 있고, 상이한 SQL 내장형 또는 사용자 정의 타입으로 될 수 있는 데이터 멤버 컬렉션인 내부 표현을 갖는 타입인 "구조형(structured type)"을 설명했다. 이것은 C 및 C++에서의 구조체 개념과 유사하다. SQL-99는 사용자가 단지 그 내부 구조와 관련하여 타입을 정의할 필요 가 있는 구조형을 정의하는 스타일을 설명한다. 시스템은 그 타입의 인스턴스의 온-디스크 표현을 관리하기 위해 데이터 멤버, 구성자 및 함수에 관한 접근자 및 변경자 함수를 자동으로 생성한다.

SQL에 정의된 바와 같은 구조형의 특별한 장점은 (a) 타입의 기본 행위 정의의 용이함, 및 (b) 더욱 복잡한 타입을 정의하기 위한 융통성이다. 그러나, 구조형의 중요한 단점은 C 또는 C++와 같은 범용 프로그래밍 언어로 작성된 외부 함수를 통해 보통 정의되는 타입-지정 메소드의 정의의 복잡성이다. 구조형을 완전히 정의하기 위해, 타입의 디파이너(definer)는 SQL과 소정의 다른 프로그래밍 언어 사이의 라인에 걸쳐있을 필요가 있다.

SQL 99의 디스팅트 타입 및 구조형 특징들은 SQL 데이터베이스의 현존하는 스칼라 타입 시스템을 확장할 수 있게 해준다는 면에서 사용자들에게 몇 가지 장점을 제공하지만, 스칼라 타입으로서 작용하지만 더욱 복잡한 구조 및 행위를 포함하는 사용자 정의 타입을 통해 사용자가 데이터베이스 시스템의 스칼라 타입 시스템을 확장할 수 있게 하는 개선된 시스템 및 방법을 필요로 했다.

"System and Method for Providing User Defined Types in a Database System"이란 발명의 명칭으로 2004년 2월 10일자로 출원된 미합중국 특허 출원 제10/775,282호((Atty.Docket No. MSFT-3029/307007.01)(이후, UDT 특허 출원이라 함)에 개시된 발명은 스칼라 타입으로서 작용하지만 더욱 복잡한 구조 및 행위를 포함하는 사용자 정의 타입을 작성함으로써 사용자가 데이터베이스 시스템의 스칼라 타입 시스템을 확장할 수 있게 하는 시스템 및 방법에 관한 것이다. 상기 발명에 따르면, 사용자는 사용자 정의 타입의 구조를 정의하는 클래스, 및 사용자 정의 타입의 인스턴스에 관해 호출될 수 있는 메소드를 구현하는 고수준 프로그래밍 언어로 프로그램 코드를 작성한다. 상기 발명(및 본 발명)에서 사용된 바와 같이, "구조"라는 용어는 사용자 정의 타입을 언급할 때, 그 타입을 구현하는 필드 또는 특성(property)의 세트를 모두 포함하는 것이다. UDT 특허 출원에서의 각 필드의 타입은 스칼라 SQL형 또는 임의의 사전 정의된 사용자 정의 타입일 수 있다. 그 다음, 사용자 정의 타입을 정하는 클래스는 컴파일되어 데이터베이스 시스템에 등록된다. 구체적으로, 사용자 정의 타입을 정하는 CLR 클래스는 어셈블리로 컴파일될 수 있으며, 이 어셈블리는 다음에 CREATE ASSEMBLY 데이터 정의 문장을 통해 데이터베이스 시스템에 등록된다. 어셈블리가 등록된 후, 사용자는 CREATE TYPE 데이터 정의 문장을 사용하여 사용자 정의 타입을 정하는 어셈블리 내에 클래스를 등록할 수 있다.

UDT 특허 출원의 발명에 있어서, 데이터베이스 시스템은 사용자 정의 타입이 SQL형 시스템에서 스칼라로서 작용할 수 있도록 클래스가 구현해야 하는 특정 약정을 시행한다. 상기 발명(및 본 발명)에서 사용되는 "약정"이라는 용어는 실행될 코드가 적절하게 실행될 것이라는 것을 보장하기 위한 소정의 사전-조건 또는 요구사항을 만족시키는지 확인하기 위해 객체 지향 프로그래밍 환경에서 런타임 시에 사용되는 기술을 칭하는 것이다. 상기 발명에 따르면, 사용자 정의 타입을 정하는 클래스가 비교되는 약정은 몇가지 요구사항을 포함한다. 첫째, 클래스는 데이터베이스 저장소 내에 사용자 정의 타입의 인스턴스를 지속시키기 위해 다수의 상이한 포맷들 중 하나를 지정해야 한다. 둘째, 클래스는 사용자 정의 타입에 대한 널(null) 값을 복귀시킬 수 있어야 된다. 셋째, 클래스는 스트링 타입과 같은 다른 타입으로/으로부터 사용자 정의 타입을 변환하는 방법을 제공해야 한다. 일단 이러한 요구사항이 만족되면, 데이터베이스 시스템은 사용자 정의 타입의 인스턴스가 작성될 수 있게 한다. 상기 출원의 한 실시예에서, 사용자 정의 타입은 테이블 내의 열(column) 값, 변수, 루틴의 파라미터, 또는 루틴의 복귀 값으로서 인스턴스화될 수 있다. 데이터베이스 시스템은 타입의 인스턴스 작성시 후속 사용을 위해 사용자 정의 타입을 정하는 클래스에 대한 메타데이터를 저장한다. 상기 발명의 다른 실시예에서, 사용자 정의 타입 약정의 검증은 타입을 정하는 클래스를 설명하는 메타데이터를 사용하여 실행된다.

사용자 정의 타입의 인스턴스를 지속시키기 위한 다수의 상이한 포맷은 사용자 정의 타입의 인스턴스가 데이터베이스 시스템의 원시 포맷에 따라 자동으로 직렬화되는 제1 포맷, 및 사용자 정의 타입의 인스턴스가 사용자 작성 클래스에 의해 정해진 방식으로 직렬화되는 제2 포맷을 포함한다. 부수적으로, UDT 특허 출원의 발명이 MICROSOFT.NET CLR이 통합되는 MICROSOFT SQL SERVER 내에서 구현되면, 사용자 정의 타입의 인스턴스가 MICROSOFT.NET 프레임워크에 의해 제공된 방법에 따라 직렬화되는 제3 포맷이 이용가능하다.

UDT 특허 출원의 발명에 있어서, 데이터베이스 시스템의 조회 언어의 표현식은 표현식의 평가가 사용자 정의 타입의 인스턴스에 관한 메소드의 호출을 요구하도록, 사용자 정의 타입의 인스턴스(들)에 대한 하나 이상의 참조를 포함할 수 있 다. 데이터베이스 시스템은 그러한 조회 언어 표현식을 수신하면, 그 표현식을, 실행시에 사용자 정의 타입의 인스턴스에 관해 요구된 메소드를 호출하는 프로그램 코드 명령어의 시퀀스로 번역한다. 그 다음, 데이터베이스 시스템은 메소드 호출의 결과를 조회 언어 표현식의 평가 결과로서 복귀시킨다. 한 실시예에서, 사용자 정의 타입의 인스턴스는 인스턴스에 관한 메소드를 호출하기 전에 역직렬화된다.

상기 발명의 다른 특징은 변경자 메소드의 호출을 통해 사용자 정의 타입의 인스턴스의 값을 변경하는 능력이다. 구체적으로, 사용자 정의 타입을 정하는 클래스의 작성자는 클래스의 일부로서 변경자 메소드를 포함한다. 사용자 정의 타입의 인스턴스에 관해 호출했을 때, 변경자 메소드는 사용자 정의 타입의 값이 변경될 수 있게 한다. 이 프로세스는 사용자 정의 타입의 인스턴스의 역직렬화, 인스턴스의 역직렬화 데이터의 값을 변경하기 위한 변경자 메소드의 호출, 및 다음에 변경을 지속시키기 위한 사용자 정의 타입의 변경된 인스턴스의 직렬화를 포함할 수 있다.

상기 발명의 다른 특징은 사용자 정의 타입의 인스턴스의 직렬화된 이진 표현이 이진 순서화될 것이라는 것을 지정하는 속성을, 사용자 정의 타입을 정하는 클래스가 더욱 포함할 수 있다는 것이다. 이것은 타입의 인스턴스에 관해 이진 비교가 행해질 수 있게 하고, 또한 타입의 인스턴스에 관해 인덱싱이 실행될 수 있게 한다. 구체적으로, 이진 순서화되는 사용자 정의 타입의 인스턴스에 대해, 타입의 2가지 인스턴스의 어떤 비교를 필요로 하는 조회 언어 표현식이 데이터베이스 시스템에 의해 수신될 때(예를 들어, >,<,또는 =), 2가지 인스턴스의 직렬화된 이진 표 현은 어느 한 인스턴스를 역직렬화하지 않고, 표현식을 평가하기 위해 사용될 수 있다. 부수적으로, 이진 순서화되는 사용자 정의 타입에 대해, 사용자 정의 타입으로서 정해진 열을 갖는 데이터베이스 저장소 내의 테이블이 작성될 수 있다. 그 다음, 인덱스가 열 상에 작성될 수 있다. 인덱스는 또한 사용자 정의 타입을 참조하는 조회 언어 표현식을 통해 작성될 수 있다. 이 경우에, 계산된 열이 먼저 표현식을 통해 생성된 다음에, 계산된 열을 통해 인덱스가 작성된다.

컬렉션

데이터-집약 애플리케이션은 실세계(real-world) 부분을 캡처(capture)하기 위해 객체 데이터 모델을 사용한다("객체 데이터 모델링"으로도 공지됨). 엔티티(예를 들어, 아이템 기반의 하드웨어/소프트웨어 인터페이스 시스템에서의 "아이템") 및 관계는 2개의 공통 데이터 모델링 구성체이다. 예를 들어, Author 및 Document가 2개의 엔티티 타입인 경우, 몇몇 예만 들자면, "all documents written by an author" 및 "all documents reviewed by an author"와 같이, Author와 Document 사이에 몇가지 관계가 있을 수 있다.

엔티티는 스칼라-값 및/또는 컬렉션-값(또는 세트-값)일 수 있는 특성 세트를 포함한다. 예를 들어, Author 엔티티는 작성자의 전화번호 세트뿐만 아니라 주소 세트에 대한 컬렉션-값 특성뿐만 아니라, 작성자의 이름 및 생일에 대한 스칼라-값 특성을 포함할 수 있다. 이들 컬렉션-값 특성은 스칼라-값 특성처럼, 엔티티에 임베드(embed)되고-즉, 그들은 그 엔티티의 일부로 간주되고, 그 엔티티로부터 다른 엔티티로 꼭 정의된 관계는 아니다. 그들 컬렉션("임베디드 컬렉션"이라고도 함)의 각각은 보통 작은 수의 멤버(또는 "요소")를 포함하고, 어떤 경우에, 이들 컬렉션의 멤버는 (예를 들어, 작성자가 1차 주소, 2차 주소 등등을 가질 때) 상대적인 중요 순서를 가질 수 있다. 여기에서 사용될 때, 비순서화된 컬렉션은 "멀티세트"로 칭해지는 반면, 순서화된 컬렉션은 "리스트"로 칭해지고, 리스트는 멀티세트의 연장으로서, 컬렉션 내의 멤버들의 상대 순서를 더욱 설명한다.

확장가능 관계형 데이터 저장소

컬렉션은 현존하는 데이터베이스 제품으로 구현되었지만, 이들 제품은 보통 일차 키-외래 키 개념과 같은 값-기반의 관계를 사용하여 컬렉션을 모델링하는데, 그 자체로는 관계형 조회가능 객체로서 취급될 수 없다. 게다가, 컬렉션에 대한 조회-예를 들어, "return all contacts who live in city X"-는 상기 컬렉션이 관계형 조회가능 객체가 아니기 때문에 일반적으로 컬렉션의 모든 경로를 트래버스하는 것을 필요로 한다.

확장가능 관계형 데이터 저장소(ERDS)는 UDT의 구현을 설명하는 "System and Method for Providing User Defined Types in a Database System"이란 발명의 명칭으로 2004년 2월 10일자로 출원된 미합중국 특허 출원 제10/775,282호(Atty.Docket No. MSFT-3029/307007.01)에 설명된 바와 같이, 엔티티가 사용자 정의 타입(UDT)으로서 모델링될 수 있게 하는 관계형 데이터 저장소이다. ERDS에서는, 이들 컬렉션을 사용자 정의 타입(UDT)의 일부분으로서 모델링하는 것이 더욱 자연스럽고 편리할 수 있으며, 여기에서, 컬렉션 UDT는 적절하게 스칼라 및 관계형으로서 취급될 수 있다. 그러므로, 본 분야에 필요한 것은 스칼라로서 프로세스되거나 관계형으 로서 조회될 수 있는 하나의 컬렉션뿐만 아니라 ERDS 내의 UDT의 일부분으로서 컬렉션들을 모델링하는 방법이다.

본 발명의 몇몇 실시예는 비순서화된 컬렉션(멀티세트) 및 순서화된 컬렉션(리스트)을 위한 지원을 포함하도록 확장된 관계형 데이터 저장소(ERDS)의 UDT 프레임워크를 확장하는 시스템 및 방법에 관한 것이다. 더욱 구체적으로, 본 발명의 몇몇 실시예는 동시에 스칼라 및 관계형인 컬렉션에 대한 특정 타입 추상화를 작성하여 이용하기 위해 UDT 기반구조, CLR 제너릭(generics), 및 새로운 UNNEST 연산자를 사용한다. 스칼라로서, 이 컬렉션 타입은 스칼라를 이해하는 데이터 저장소 엔진의 모든 부분(클라이언트 스택을 포함하지만 이것에 제한되지 않음)에 의해 프로세스될 수 있고, 관계형으로서, 이 컬렉션 타입은 소정의 다른 관계형처럼 조회가능하다.

본 발명의 여러 실시예는 스칼라 및 관계형인 컬렉션 타입을 포함하는 데이터 저장소에 관한 것이다. 소정의 이들 실시예에 있어서, 방법은 (a) 데이터 저장소 엔진의 스칼라 타입시스템(typesystem)에 본질적으로 스칼라로서 등록되는 컬렉션 타입에 대한 UDT 추상화를 작성하는 단계, 및 (b) 필요시, 상기 컬렉션을 관계형 조회가능 객체로서 조회하기 위해 컬렉션을 언네스트하는 단계를 포함한다.

본 발명의 몇몇 실시예는 컬렉션에 적용된 스칼라 연산에 대해서는 스칼라로서 프로세스되고, 컬렉션에 적용되는 조회 연산에 대해서는 관계형으로서 조회되는 관계형 데이터 저장소 내의 엔티티에 대한 향상된 컬렉션에 관한 것이다. 소정의 이들 실시예에서, 관계형 저장소는 상기 컬렉션이 공통 언어 런타임(CLR) 내의 일반적 사용자 정의 타입으로부터 구해지고, 또한 (SQL 스칼라 타입시스템 내의) SQL 스칼라 타입인 확장가능 관계형 데이터 저장소이다. 이들 실시예의 몇몇은 컬렉션 타입, 및 컬렉션에 대응하는 사용자 정의 타입을 관계형 데이터 저장소에 등록하는 것을 필요로 한다. 또한, 소정의 실시예는 특히 상기 컬렉션을, 제1 열을 포함하는 관계형 조회가능 객체로 변환하기 위해 상기 컬렉션에 관한 언네스팅 연산을 사용하는데, 상기 제1 열의 각 행은 상기 컬렉션(즉, 멀티세트용)의 단일 멤버에 대응한다. 다른 실시예는 제2 열을 더 포함하는데, 상기 제2 열의 각 행은 상기 컬렉션의 단일 멤버에 대응하고, 각 행은 상기 순서화된 컬렉션(리스트용) 내의 각각의 상기 멤버의 순서에 대응하는 값을 갖는다. 선택된 실시예에서, 멀티세트 및 리스트는 동일한 2열 관계형 조회가능 객체를 사용한다(여기에서, 제2 열은 순서가 중요하지 않은 멀티세트의 경우에는 단순히 무시될 수 있다).

양호한 실시예에 관한 다음의 상세한 설명뿐만 아니라 상기 요약은 첨부된 도면을 참조하면 더욱 잘 이해된다. 본 발명을 예시적으로 설명하기 위해, 발명의 예시적인 구성을 도면에 도시하였지만, 본 발명은 개시된 특정 방법 및 구성에 제한되지 않는다.

본 발명의 주제는 법정 요구사항에 부합하도록 특수성이 설명된다. 그러나, 설명 자체는 본 발명의 범위를 제한하고자 하는 것이 아니다. 오히려, 발명가는 청구된 주제가 기타 현재 또는 장래의 기술과 결합하여 본 명세서에 설명된 것과 유사한 다른 단계 또는 구성요소를 포함하도록 다른 방식으로 실시될 수 있다는 것을 고려했다. 게다가, "단계"라는 용어는 이용된 방법의 상이한 양상들을 내포하기 위해 여기에서 사용될 수 있지만, 그 용어는 개별 단계들의 순서가 명확하게 설명되지 않으면, 그리고 개별 단계들의 순서가 명확하게 설명되는 경우를 제외하고는, 여기에 설명된 다양한 단계들 사이의 임의의 특정 순서를 암시하는 것으로 해석되어서는 안된다.

후술되는 실시예에서, 본 발명의 상기 특징은 MICROSOFT SQL SERVER 데이터베이스 시스템으로 구현되는 것으로 설명된다. 상술된 바와 같이, SQL SERVER는 SQL SERVER 데이터베이스의 데이터 저장소 상에서 동작하도록 관리 코드가 기입되어 실행될 수 있게 하기 위해 MICROSOFT.NET CLR을 통합한다. 후술되는 실시예는 이와 같은 상황에서 동작하지만, 본 발명은 SQL SERVER 제품에서의 구현에 결코 제한되지 않는다는 것을 충분히 알 수 있다. 오히려, 본 발명은 데이터베이스 저장소 상에서 동작하도록 객체 지향 프로그래밍 코드의 실행을 지원하는 임의의 데이터베이스 시스템, 이를테면 객체 지향 데이터베이스 시스템, 및 객체 관계 확장을 갖는 관계형 데이터베이스 시스템으로 구현될 수 있다. 따라서, 본 발명은 후술되는 특정 실시예에 제한되는 것이 아니라, 첨부된 청구범위에 정의된 바와 같이 본 발명의 정신 및 범위 내에 있는 모든 변경을 포함하고자 하는 것이라는 것을 충분히 알 수 있다.

컴퓨터 환경

본 발명의 여러 실시예는 컴퓨터 상에서 실행될 수 있다. 도 1 및 다음 설 명은 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경에 대한 간략한 일반적인 설명을 제공하고자 하는 것이다. 요구되지는 않았지만, 본 발명은 클라이언트 워크스테이션 또는 서버와 같은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 일반적으로 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 실행하거나 특정 추상 데이터형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 게다가, 본 분야에 숙련된 기술자들은 본 발명이 핸드 헬드 장치, 멀티 프로세서 시스템, 마이크로프로세서 기반 또는 프로그램 가능 소비자 전자제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 기타 컴퓨터 시스템 구성들로 실시될 수 있다는 것을 이해할 수 있을 것이다. 본 발명은 또한 통신 네트워크를 통해 링크되는 원격 프로세싱 장치에 의해 태스크가 실행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치에 위치할 수 있다.

도 1에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은 프로세싱 유닛(21), 시스템 메모리(22), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(21)에 연결시키는 시스템 버스(23)를 포함하는 종래의 퍼스널 컴퓨터(20) 등을 포함한다. 시스템 버스(23)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 제어기를 포함하는 몇가지 타입의 버스 구조 중의 임의의 것일 수 있다. 시스템 메모리는 판독 전용 메모리(ROM)(24) 및 랜덤 액세스 메모리(RAM)(25)를 포함한다. 시동중과 같은 때에 퍼스널 컴퓨터(20) 내의 구성요소들간에 정보를 전송하는 것을 돕는 기본 루 틴을 포함하는 기본 입/출력 시스템(26; BIOS)은 ROM(24)에 저장된다. 퍼스널 컴퓨터(20)는 도시되지 않은 하드 디스크로부터 판독하고 그 하드 디스크에 기록하는 하드 디스크 드라이브(27), 분리형 자기 디스크(29)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(28), 및 CD-ROM 또는 기타 광학 매체와 같은 분리형 비휘발성 광학 디스크(31)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(30)를 더 포함할 수 있다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28) 및 광학 디스크 드라이브(30)는 각각 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33) 및 광학 드라이브 인터페이스(34)에 의해 시스템 버스(23)에 접속된다. 드라이브 및 그 관련 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 및 퍼스널 컴퓨터(20)용의 기타 데이터의 비휘발성 저장을 제공한다. 여기에 설명된 예시적인 환경은 하드 디스크, 분리형 자기 디스크(29) 및 분리형 광학 디스크(31)를 이용하지만, 본 분야에 숙련된 기술자들은 자기 카세트, 플래쉬 메모리 카드, 디지털 비디오 디스크, 베르누이 카트리지, RAM, ROM 등과 같이 컴퓨터에 의해 액세스가능한 데이터를 저장할 수 있는 다른 타입의 컴퓨터 판독가능 매체가 또한 예시적인 동작 환경에서 사용될 수 있다는 것을 알 수 있을 것이다.

다수의 프로그램 모듈은 운영 체제(35), 하나 이상의 응용 프로그램(36), 기타 프로그램 모듈(37) 및 프로그램 데이터(38)를 포함하는, 하드 디스크, 자기 디스크(29), 광학 디스크(31), ROM(24) 또는 RAM(25) 상에 저장될 수 있다. 사용자는 키보드(40) 및 포인팅 장치(42)와 같은 입력 장치를 통해 퍼스널 컴퓨터(20) 내 로 커맨드 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 직렬 포트 인터페이스(46)를 통해 종종 프로세싱 유닛(21)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB)와 같은 기타 인터페이스에 의해 접속될 수 있다. 모니터(47) 또는 다른 타입의 디스플레이 장치는 또한 비디오 어댑터(48)와 같은 인터페이스를 통해 시스템 버스(23)에 접속된다. 모니터(47) 외에도, 퍼스널 컴퓨터는 전형적으로 스피커 및 프린터와 같은 기타 주변 출력 장치(도시되지 않음)를 포함한다. 도 1의 예시적인 시스템은 또한 호스트 어댑터(55), 소형 컴퓨터 시스템 인터페이스(SCSI) 버스(56), 및 SCSI 버스(56)에 접속된 외부 저장 장치(62)를 포함한다.

퍼스널 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(49)는 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 1 에는 메모리 저장 장치(50)만이 도시되어 있지만, 퍼스널 컴퓨터(20)에 관하여 상술한 구성요소 중 다수 또는 모든 구성요소를 일반적으로 포함할 수 있다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN; 51) 및 원거리 통신망(WAN; 52)을 포함한다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 퍼스널 컴퓨터(20)는 네트워크 인터 페이스 또는 어댑터(53)를 통해 LAN(51)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 퍼스널 컴퓨터(20)는 일반적으로 인터넷과 같은 WAN(52)을 통해 통신을 구축하기 위한 모뎀(54) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(54)은 직렬 포트 인터페이스(46)를 통해 시스템 버스(23)에 접속된다. 네트워크 환경에서, 퍼스널 컴퓨터(20)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있다는 것을 알 수 있을 것이다.

본 발명의 여러 실시예는 특히 컴퓨터화 시스템에 매우 적합한 것으로 생각되지만, 본 명세서에서 본 발명을 그러한 실시예에 제한하고자 하는 것은 결코 아니다. 도리어, 여기에서 사용되는 바와 같이, "컴퓨터 시스템"이라는 용어는 장치의 특성이 전자적이든지, 기계적이든지, 논리적이든지, 가상적이든지 상관없이, 정보를 저장하고 프로세싱할 수 있고/있거나, 장치 자체의 행위 또는 실행을 제어하기 위해 저장된 정보를 사용할 수 있는 임의의 장치 및 모든 장치를 포함하고자 하는 것이다.

UDT 및 관리 코드

도 2는 사용자 정의 타입(UDT)의 인스턴스의 직렬화 및 역직렬화를 도시한 블록도이다. 도시된 바와 같이, UDT의 인스턴스는 메모리 내의 인스턴스를 나타내는 객체의 직렬화를 통해 디스크 상에 지속된다. 애플리케이션이 UDT의 인스턴스의 메소드를 참조하는 술어 또는 표현식을 포함하는 조회를 발생시킬 때, 인스턴스 의 지속 형태는 역직렬화되고("하이드레이션(hydration)"이라고도 칭해지는 프로세스), CLR은 자체 저장된 값을 수신하기 위해 전체 객체를 위한 메모리를 할당한다. 그 다음, CLR은 애플리케이션 또는 사용자에 의해 요구된 행위를 구현하는 객체에 관한 적절한 메소드를 호출한다.

상술된 바와 같이, UDT는 SQL SERVER에 등록된 어셈블리로 구현된 관리 타입이다. UDT는 테이블 정의 변수 및 파라미터를 포함하여, 고유 타입이 사용될 수 있는 대부분의 문맥에서 사용될 수 있다. UDT 약정에 따르는 UDT에 정의된 메소드, 특성 및 필드는 T-SQL로부터 호출될 수 있다. 본질적으로, UDT는 행위를 갖는 단순한 스칼라인 것으로 가정된다. 이 가정은 단순한 프로그래밍 모델, 및 UDT에 의해 지원된 직렬화 레이아웃에 반영된다. 이 구조는, 단순한 스칼라가 아니라 복잡한 구조 및 행위를 갖는 타입일 수 있는 "구조형"을 작성하기 위해 UDT 추상화에 사용될 수 있다.

컬렉션 - - 멀티세트

본 발명의 여러 실시예는 동시에 스칼라이고 관계형인-즉, 스칼라 타입으로서, 이 타입은 (클라이언트 스택을 포함하여) 스칼라를 이해하는 데이터 저장 엔진의 모든 부분을 통해 흐를 수 있고, 관계형으로서, 이 타입은 조회가능함- 데이터 저장 추상화(또는 타입)에 관한 것이다. 이들 실시예 중의 몇몇은 그러한 이원적인 타입을 함께 가능하게 하기 위해 UDT 기반구조, CLR 제너릭 및 새로운 UNNEST 연산자를 사용한다.

도 3은 확장가능 관계형 데이터 저장소(ERDS)가 이원적인 컬렉션 타입을 제 공할 수 있게 하는 일반적 방법을 도시한 프로세스 흐름도이다. 그러한 타입의 컬렉션을 구현하기 위해, 단계(302)에서, CLR 제너릭 특징은 일반적 타입, 예를 들어 Collection<T>를 정의하기 위해 사용된다. 이 타입은 "시스템 UDT"(즉, 한 곳에서 정의되고 모든 데이터베이스에서 자동으로 이용가능한 UDT)로서 작성되고, SQL 스칼라 타입시스템의 제1 클래스 부분이다. 그것만으로, 이 타입은 열 정의, 변수, 함수 인수, 및 저장된 절차 파라미터와 같이 스칼라 타입이 지원되는 모든 문맥에서 사용될 수 있다. 이들 타입은 또한 스칼라 표현식 평가 문맥에서 지원된다.

단계(304)에서, 일반적 타입은 그 다음, 일반적 컬렉션 타입의 파생형-즉, 상기 멤버가 더 이상 일반적이지 않고 대신에 스칼라 타입 또는 다른 복잡한 타입으로서 정의되는 타입-과 같은 구체적 컬렉션 타입을 작성하기 위해 사용될 수 있다. 이 예에서, 구체적 타입은 개별 멤버들이 스칼라 스트링 타입으로 되어 있는 주소를 위한 것이다. 대안적인 실시예에서, 개별 멤버들은 대신에, 제1 스트링(스트리트 주소용), 제2 스트링(시티용), 한쌍의 문자(스테이트용) 및 5개의 정수 숫자(지프 코드용)를 포함하는 복잡한 타입일 수 있다.

컬렉션이 특정 타입의 요소들을 포함하도록 선언되면, 그 UDT의 임의의 부분형(subtype)의 값은 ("대체성(substituability)"이라고 하는) 그 컬렉션에 저장될 수 있다. 컬렉션 타입과 그 요소-타입 사이의 관계는 타입 작성시에 메타데이터에 기록되고, 조회가능 카탈로그 뷰를 통해 이용가능한데, 조회가능 카탈로그 뷰는 이번에는, 애플리케이션이 특정 컬렉션 타입의 대체가능 범위를 결정하기 위한 조회를 구성할 수 있게 한다.

단계(306)에서, 새로운 구체적 컬렉션 타입은 엔티티 자체가 인스턴스화되면 엔티티 내의 특성으로서 사용될 수 있다. 이때, 순서 컬렉션은 데이터 저장소 엔진이 이 컬렉션 타입의 특별한 특징을 인식하고 컬렉션을 관계형으로서 프로세스하는 경우에, 조회가 적용되지 않으면 본질적으로 스칼라 특성으로서 취급된다.

컬렉션을 네비게이트하기 위해, 조회는 통상적으로, "return all contacts who live in city X"와 같은 조회에 응답하기 위해 컬렉션을 통하는 통로를 트래버스하도록 요구될 수 있다. 그러나, 본 발명의 몇몇 실시예의 경우, 조회 엔진은 이 특별한 컬렉션 시스템 타입-예를 들어, "Collection<T>-이 UDT와 관련된 스칼라 의미 이외에 관계형 의미를 갖고있고, 새로운 관계형 연산자 "UNNEST"가 필요시에 이 스칼라를 관계형 조회가능 객체로 변환하도록 사용되어야 한다는 것을 인식한다. 이 연산자는 테이블-값 함수가 지원되는 모든 문맥에서 지원되고, UNNEST 연산자를 포함하는 뷰 정의는 인덱스가능하다.

도 4는 엔티티 내의 컬렉션에 적용되는 조회를 프로세스하는 일반적 방법을 도시한 프로세스 흐름도이다. 단계(402)에서, 컬렉션이 데이터 저장소 엔진에 대해 SQL 에러를 발생시킬 수 있는 어떤 컬렉션은 아니었는지, 컬렉션에 대해 조회가 이루어지고, 대신에, 데이터 저장소 엔진은, 단계(404)에서 컬렉션이 특정 데이터형이라는 것을 인식하고, 단계(406)에서 조회가능 객체 - 멀티세트의 경우, 이 예에서 단일 열 테이블 -를 생성하기 위해 컬렉션을 언네스트하며, 단계(408)에서 이 조회가능 객체로 조회를 다시 향하게 한다.

예를 들어, 도 5는 조회시에 조회가능 객체(단일-열 테이블)(510')로 언네스 트되는 임베디드 필드(510)로서 특히 어드레스의 멀티세트를 갖는 구조화 UDT인 "Person" 엔티티(500)를 도시한 블록도이다. Person에 대한 관리 타입 정의는 다음과 같다:

[SqlUDT(Format.Structured)]

public class Person

{

...

Collection<Address> Addresses;

...

}

이 타입을 작성하기 위해, 임베디드 컬렉션 타입은 다음과 같이 저장소에 먼저 등록된다:

create type SetOfAddresses from Collection<Address>

go

다음에 format.structed UDT는 다음과 같이 등록된다:

create type Person external name [asm]:[Person]

go

그 후, 어드레스 세트를 스칼라로서 복귀시키기 위해, 다음의 커맨드가 사용될 수 있다:

select pcol.Addresses from t

이와 유사하게, UDT 및 임베디드 컬렉션에 관한 메소드를 호출하기 위해, 다음의 커맨드가 사용될 수 있다:

select pcol.Name, pcol.Addresses.Count from t

컬렉션 내로 조회하기 위해, 이를테면 워싱톤주에 주소를 갖는 모든 사람을 찾기 위해, 다음의 커맨드가 사용될 수 있다:

select pcol from t cross apply unnest(pcol.Addresses) a

where a.state = 'WA'

그리고, Person을 갱신하기 위해, 이를테면 그 사람의 모든 어드레스에 대한 주를 워싱톤주로 변경하기 위해, 다음의 커맨드가 사용될 수 있다:

update t

set pcol.(update Addresses set State = 'WA')

where pcol.id = 23

이와 마찬가지로, 컬렉션에 관한 변경자 메소드를 호출하기 위해, 다음의 커맨드가 사용될 수 있다:

update t

set pcol.Addresses.Clear()

where pcol.id = 23

본 발명의 특정 실시예에서, 구현 프레임워크는 시스템 UDT, CLR 제너릭, 및 스트리밍 테이블-값 함수 기반구조를 이용하는 UNNEST 연산을 사용한다.

시스템 UDT는 사용자 정의 타입(UDT) 기반구조를 사용하여 구현되는 시스템 타입이다. 시스템 UDT는 다음과 같은 방식에서 최종 사용자 작성 UDT와 다르다: (a) 시스템 UDT는 모든 데이터베이스에서 이용가능하고, 모든 사용자에게 액세스가능하며; (b) 시스템 UDT는 최종 사용자에 의해 작성되거나 삭제될 수 없고; (c) 시스템 UDT는 시스템 내에 단일의 그러한 타입이 있는 것처럼 데이터베이스 전반을 통해 사용될 수 있으며(즉, 한 데이터베이스 내의 시스템 타입의 인스턴스가 다른 데이터베이스로부터 사용가능할 것임)("타입 고유성"); (d) 시스템 UDT는 (System.Data.dll과 같은) "시스템" 어셈블리로 구현될 수 있고, 이 시스템 어셈블리는 데이터베이스 이외의 어느곳(예를 들어, 디스크)으로부터 로드되는 기본 CLR 기반구조의 일부분일 수 있으며; (e) 시스템 UDT는 SYS 스키마(schema)의 일부분이므로, 사용자가 시스템 UDT와 동일한 이름을 갖는 그 자신의 UDT를 작성할 수는 없을 것이다.

제너릭은 각각의 "구체적 인스턴스화"(이를테면 Multuset<Address> 또는 Multiset<PhoneNumber>)에 대한 타입-안전 구현을 하면 그후 "일반적 멀티세트"를 전체적으로 정의하게 할 수 있는 컬렉션 클래스 라이브러리에 사용될 수 있는 파라미터화된 타입 정의(이를테면 Multiset<T>)이다 - 즉, Multiset<T>는, 예를 들어 UDTextensions.dll에서 한번 정의되는 일반적 시스템 UDT이다.

UNNEST 연산자는 타입 Multiset<T>의 UDT를 취하고(또는 그 SQL형은 다른 구체적 멀티세트 타입임), 그것을 단일-열 테이블로 변환하며, 상기 열의 각 행은 상기 컬렉션의 멤버에 대응하므로, 상기 컬렉션 멤버의 온더플라이(on-the-fly) 조회 및 네비게이션을 가능하게 한다. 본 발명의 소정의 실시예에서, 바인딩(binding) 프로세스 동안에, 특정 네임스페이스는 UNNEST 연산에 의해 생성된 열에 대해 작성되고, UNNEST 연산 자체는 스트리밍 테이블 값 함수가 된다. 이 최적화는 부수적인 데이터 카피의 필요성 없이 스칼라에서 관계형으로의 컬렉션의 변환이 일어날 수 있게 한다. 이 방식은 또한 결과들이 중복된 실체화없이 소모될 수 있도록 결과들에 관한 스크리밍 모델을 제공한다. (스트리밍 테이블 값 함수는 "System and Method for Fragment-Based Serialization"이란 발명의 명칭으로 2004년 4월 9일자로 출원된 미합중국 특허출원 제10/821,687호(Atty.Docket No. MSFT-2955/307064.01)에 설명된다.

컬렉션 - - 리스트

리스트는 컬렉션 멤버의 순서를 얻기 위해 확장된 컬렉션이다. 멀티세트와 유사하게, 이 타입의 값은 변수, 파라미터, 복귀 값 및 열 정의를 포함하여, 스칼라 UDT 값이 허용되는 모든 문맥에서 사용될 수 있다. 리스트는 또한 고유하게 스칼라 컬렉션 값을 관계형으로 변환하는 UNNEST 함수로 실행되고; 그러나, UNNEST에 의해 생성된 관계형 스키마는 최소한 2개의 열을 가질 수 있는데, 한 열은 멤버(행 당 한 멤버)를 포함하고, 다른 한 열(또는 의사-열 또는 가상 열)은 상기 리스트 내의 상기 멤버의 상대 순서를 나타내는 값, 예를 들어 주어진 구성요소의 서수를 포함한다. 도 6은 조회가 멀티세트 대신에 리스트에 관한 것일 때 작성되는 도 5로부터의 조회가능 객체(510")를 도시한 부분 블록도이다. 또한, 멀티세트에서와 같이, TSQL DML은 타입 리스트의 값에 관한 어레이 액세스 연산을 지원하도록 확장될 수 있다.

(변환 행렬 및 상호 데이터베이스 문맥의 사용을 포함하여) 이 타입에 대한 직교 행렬 약정의 나머지에 대해서는 (후술되는 바와 같이) Format.Structured UDT에 대한 것과 동일하게 가정된다. 게다가, "리스트"는 "어레이"로도 칭해질 수 있는데, 어레이는 SQL99 표준에서 사용되는 용어이다.

다음예는 어드레스 및 전화번호에 대한 2개의 리스트-값 특성을 포함하는 대안적인 UDT Person 클래스를 나타낸 것이다:

[SqlUdt(Format.Structured)]

class Person {

String Name;

DateTime Birthdate;

SqlList<Address> Addresses;

SqlList<Phone> Phones;

}

상기 타입 SqlList<Address> 및 SqlList<Phone>은 새로운 데이터 정의 언어(DDL) 문장을 사용하여 SQL Server에 정의된다:

create type ListOfAddress from LIST<Address>

create type ListOfPhone from LIST<Phone>

그 다음, 다음 문장은 테이블 Person의 열을 갖는 테이블을 작성한다:

create table Persons (pcol Person)

이것이 완료되면, 다음 문장은 다음과 같이 2개의 주소 및 3개의 전화를 갖는 Person 인스턴스를 작성하기 위해 사용될 수 있다:

declare @p Person, @a1 Address, @a2 Address

declare @p1 Phone, @p2 Phone, @p3 Phone

set @p = convert (Person, "John Smith, 11/11/1977")

set @a1 = convert (Address, "6138 205th DR NE, Redmond, WA, 98053")

set @a2 = convert (Address, "15765 99th Ave NE, Seattle, WA, 98001")

set @p1 = convert (Phone, "Office, 206 686 3452")

set @p2 = convert (Phone, "Home, 425 708 6456")

set @p3 = convert (Phone, "Cell, 425 277 3242")

set @p.Addresses[1] = @a1

set @p.Addresses[2] = @a2

set @p.Phones[1] = @p2

set @p.Phones[2] = @p1

set @p.Phones[3] = @p3

insert into Persons values (@p)

그 후, 다음과 같이 일차 주소가 Seattle에 있는 Persons 테이블 내의 사람들의 모든 이차적인 주소 및 전화번호를 조회할 수 있다.

select pcol.name, pcol.addresses[2], pcol.Phones[3] from Persons

where pcol.addresses[1].city = "Seattle"

다시 한번, UNNEST는 리스트를 인수로서 다루고, 한 행이 리스트의 각 요소 를 위한 것인 한 세트의 행을 생성하는 구성체이다. UNNEST는 2개의 열을 생성하는데, 한 열은 멤버 구성요소를 위한 것이고, 다른 한 열은 리스트 내의 각 멤버의 상대 순서(예를 들어, 대응하는 구성요소 우선순위의 서수 값)를 위한 것이다.

결론

여기에 설명된 여러가지 시스템, 방법 및 기술은 하드웨어 또는 소프트웨어로, 또는 적절한 경우에 그 둘의 조합으로 구현될 수 있다. 그러므로, 본 발명의 방법 및 장치, 또는 소정의 실시양상 또는 그 일부는 플로피 디스켓, CD-ROM, 하드 드라이브, 또는 임의의 다른 기계 판독가능 저장 매체와 같은 타입의 매체에 구현된 프로그램 코드(즉, 명령어)의 형태를 취할 수 있는데, 프로그램 코드가 컴퓨터와 같은 기계 내로 로드되어 그 기계에 의해 실행될 때, 그 기계는 본 발명을 실시하는 장치가 된다. 프로그램가능 컴퓨터 상에서의 프로그램 코드 실행의 경우에, 컴퓨터는 일반적으로 프로세서, 프로세서에 의해 판독가능한 저장 매체(휘발성 및 비휘발성 메모리 및/또는 저장 소자 포함), 최소한 하나의 입력 장치, 및 최소한 하나의 출력 장치를 포함할 수 있다. 하나 이상의 프로그램은 양호하게 컴퓨터 시스템과 통신하기 위해 고수준 절차 또는 객체 지향 프로그래밍 언어로 구현된다. 그러나, 프로그램(들)은 원한다면 어셈블리 또는 기계어로 구현될 수 있다. 어떤 경우든, 언어는 컴파일러형 또는 해석형 언어일 수 있고, 하드웨어 구현물과 결합될 수 있다.

본 발명의 방법 및 장치는 또한 전선 또는 케이블링, 광 섬유, 또는 임의의 다른 전송 형태와 같은 소정의 전송 매체를 통해 전송되는 프로그램 코드의 형태로 구현될 수 있는데, 프로그램 코드가 EPROM, 게이트 어레이, 프로그램가능 로직 디바이스(PLD), 클라이언트 컴퓨터, 비디오 레코더 등과 같은 기계 내로 수신되어 로드되고 그 기계에 의해 실행될 때, 그 기계는 본 발명을 실시하는 장치가 된다. 범용 프로세서 상에서 구현될 때, 프로그램 코드는 본 발명의 인덱싱 기능을 실행하도록 동작하는 유일한 장치를 제공하기 위해 프로세서와 결합한다.

본 발명은 여러 도면의 양호한 실시예와 관련하여 설명되었지만, 그외 다른 유사한 실시예가 사용될 수 있거나, 본 발명의 범위를 벗어나지 않고 본 발명의 동일한 기능을 실행하는 설명된 실시예에 대해 변경 및 추가가 행해질 수 있다는 것을 충분히 알 수 있다. 예를 들어, 본 발명의 예시적인 실시예는 퍼스널 컴퓨터의 기능을 에뮬레이션하는 디지털 장치와 관련하여 설명되지만, 본 분야에 숙련된 기술자는 본 발명이 그러한 디지털 장치에 제한되지 않고, 본 출원에 설명된 바와 같이, 유선 또는 무선의, 게이밍 콘솔, 핸드헬드 장치, 포터블 컴퓨터 등과 같은 임의의 수의 기존의 또는 새로운 컴퓨팅 장치 또는 환경에 적용할 수 있으며, 통신 네트워크를 통해 접속되어 네트워크를 통해 상호작용하는 임의의 수의 그러한 컴퓨팅 장치에 적용될 수 있다는 것을 알 수 있을 것이다. 더욱이, 무선 네트워크 장치의 수가 계속 증가함에 따라, 핸드헬드 장치 운영 체제 및 그외 다른 애플리케이션 특정 하드웨어/소프트웨어 인터페이스 시스템을 포함하는 여러가지 컴퓨터 플랫폼이 본 발명에서 고려된다는 것이 강조되어야 한다. 그러므로, 본 발명은 소정의 한 실시예에 제한되는 것이 아니라, 첨부된 청구범위에 따른 범위 내에에서 해석되 어야 한다.

Claims (20)

1. 관계형 데이터 저장(relational data store) 방법으로서,

   확장가능 관계형 데이터 저장소에서 컬렉션(collection)에 적용될 연산을 수신하는 단계 - 상기 컬렉션은 공통 언어 런타임(Common Language Runtime: CLR)에서의 일반적(generic) 사용자 정의 타입(User-Defined Type: UDT)으로부터 구해지고, 구조화 조회 언어(Structured Query Language: SQL) 스칼라(scalar) 타입이며, 상기 컬렉션은 스칼라로서 프로세스가능하고 그 동일한 컬렉션은 관계형(relation)으로서 조회가능하며, 상기 연산은 스칼라 연산 또는 조회 연산임 - ;

   상기 컬렉션에 적용된 스칼라 연산들에 대해서는, 상기 컬렉션을 스칼라로서 프로세스하는 단계;

   상기 컬렉션에 적용된 조회 연산들에 대해서는, 상기 컬렉션을 관계형으로서 조회하는 단계 - 상기 컬렉션을 관계형으로서 조회하는 단계는,

   상기 컬렉션을 조회가능한 관계형으로서 인식하는 단계,

   상기 컬렉션을 언네스트(unnest)하여 조회가능 객체를 생성하는 단계, 및

   상기 조회가능 객체에 대하여 상기 조회 연산들을 수행하는 단계

   를 포함함 - ; 및

   상기 프로세스하는 단계 또는 상기 조회하는 단계의 결과들을 저장하는 단계

   를 포함하는 방법.
2. 제1항에 있어서,

   상기 일반적 사용자 정의 타입은 시스템 사용자 정의 타입인 방법.
3. 제2항에 있어서,

   상기 컬렉션 타입을 상기 관계형 데이터 저장소에 등록하는 단계; 및

   상기 컬렉션에 대응하는 사용자 정의 타입을 상기 관계형 데이터 저장소에 등록하는 단계

   를 더 포함하는 방법.
4. 제3항에 있어서,

   상기 컬렉션을 관계형으로서 조회하는 상기 단계는,

   상기 컬렉션을 제1 열을 포함하는 관계형 조회가능 객체로 언네스트하는 단계 - 상기 제1 열의 각 행은 상기 컬렉션의 단일 멤버에 대응함-; 및

   상기 관계형 조회가능 객체를 조회하는 단계

   를 포함하는 방법.
5. 제4항에 있어서,

   상기 관계형 조회가능 객체는 제2 열을 포함하고, 상기 제2 열의 각 행은 상기 컬렉션의 단일 멤버에 대응하고, 각각의 행은 순서화된 컬렉션 내의 각각의 상기 멤버의 순서에 대응하는 값을 갖는 방법.
6. 제2항에 있어서,

   상기 방법은 하드웨어 제어 장치에 의해 구현되고, 상기 하드웨어 제어 장치는 상기 방법의 각 단계를 구현하기 위한 수단을 포함하는 방법.
7. 관계형 데이터 저장 방법을 구현하기 위한 컴퓨터 판독가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서, 상기 컴퓨터 판독가능 명령어들은,

   확장가능 관계형 데이터 저장소에서 컬렉션에 적용될 연산을 수신하는 단계 - 상기 컬렉션은 공통 언어 런타임(CLR)에서의 일반적 사용자 정의 타입(UDT)으로부터 구해지고, 구조화 조회 언어(SQL) 스칼라 타입이며, 상기 컬렉션은 스칼라로서 프로세스가능하고 그 동일한 컬렉션은 관계형으로서 조회가능하며, 상기 연산은 스칼라 연산 또는 조회 연산임 - ;

   상기 스칼라 연산이 상기 컬렉션에 적용될 때, 상기 컬렉션을 스칼라로서 프로세스하는 단계;

   상기 조회 연산이 상기 컬렉션에 적용될 때, 상기 컬렉션을 관계형으로서 조회하는 단계 - 상기 컬렉션을 관계형으로서 조회하는 단계는,

   상기 컬렉션을 조회가능한 관계형으로서 인식하는 단계,

   상기 컬렉션을 언네스트하여 조회가능 객체를 생성하는 단계, 및

   상기 조회가능 객체에 대하여 상기 조회 연산을 수행하는 단계

   를 포함함 - ; 및

   상기 프로세스하는 단계 또는 상기 조회하는 단계의 결과들을 저장하는 단계

   를 수행하는 명령어들을 포함하는 컴퓨터 판독가능 저장 매체.
8. 제7항에 있어서,

   상기 일반적 사용자 정의 타입이 시스템 사용자 정의 타입이게 하는 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
9. 제8항에 있어서,

   상기 컬렉션 타입을 상기 관계형 데이터 저장소에 등록하는 단계; 및

   상기 컬렉션에 대응하는 사용자 정의 타입을 상기 관계형 데이터 저장소에 등록하는 단계

   를 수행하는 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
10. 제9항에 있어서,

    상기 컬렉션을 관계형으로서 조회하는 상기 단계가,

    상기 컬렉션을 제1 열을 포함하는 관계형 조회가능 객체로 언네스트하는 단계 - 상기 제1 열의 각 행은 상기 컬렉션의 단일 멤버에 대응함-; 및

    상기 관계형 조회가능 객체를 조회하는 단계

    를 더 포함하게 하는 명령어들을 더 포함하는 컴퓨터 판독가능 저장 매체.
11. 제10항에 있어서,

    상기 관계형 조회가능 객체가 제2 열을 포함하게 하는 명령어들을 더 포함하고, 상기 제2 열의 각 행은 상기 컬렉션의 단일 멤버에 대응하고, 각각의 행은 순서화된 컬렉션 내의 각각의 상기 멤버의 순서에 대응하는 값을 갖는 컴퓨터 판독가능 저장 매체.
12. 확장가능 관계형 데이터 저장소를 구현하기 위한 시스템으로서,

    확장가능 관계형 데이터 저장소에서 컬렉션에 적용될 연산을 수신하고 - 상기 컬렉션은 공통 언어 런타임(CLR)에서의 일반적 사용자 정의 타입(UDT)으로부터 구해지고, 구조화 조회 언어(SQL) 스칼라 타입이며, 상기 컬렉션은 스칼라로서 프로세스가능하고 그 동일한 컬렉션은 관계형으로서 조회가능하며, 상기 연산은 스칼라 연산 또는 조회 연산임 - ;

    상기 스칼라 연산이 상기 컬렉션에 적용될 때, 상기 컬렉션을 스칼라로서 프로세스하고,

    상기 조회 연산이 상기 컬렉션에 적용될 때, 상기 컬렉션을 관계형으로서 조회하고 - 상기 컬렉션을 관계형으로서 조회하는 것은,

    상기 컬렉션을 조회가능한 관계형으로서 인식하는 것,

    상기 컬렉션을 언네스트하여 조회가능 객체를 생성하는 것, 및

    상기 조회가능 객체에 대하여 상기 조회 연산을 수행하는 것

    을 포함함 - ;

    상기 프로세스 또는 상기 조회의 결과들을 저장하기 위한 프로세서 및 저장장치를 포함하는 시스템.
13. 제12항에 있어서,

    상기 일반적 사용자 정의 타입이 시스템 사용자 정의 타입이게 하는 적어도 하나의 서브시스템을 더 포함하는 시스템.
14. 제13항에 있어서,

    상기 컬렉션 타입을 상기 관계형 데이터 저장소에 등록하고;

    상기 컬렉션에 대응하는 사용자 정의 타입을 상기 관계형 데이터 저장소에 등록하기 위한 적어도 하나의 서브시스템을 더 포함하는 시스템.
15. 제14항에 있어서,

    상기 컬렉션을 제1 열을 포함하는 관계형 조회가능 객체로 언네스트하고 - 상기 제1 열의 각 행은 상기 컬렉션의 단일 멤버에 대응함-;

    상기 관계형 조회가능 객체를 조회하기 위한 적어도 하나의 서브 시스템을 더 포함하는 시스템.
16. 제15항에 있어서,

    상기 관계형 조회가능 객체가 제2 열을 포함하게 하는 적어도 하나의 서브시스템을 더 포함하고, 상기 제2 열의 각 행은 상기 컬렉션의 단일 멤버에 대응하고, 각각의 행은 순서화된 컬렉션 내의 각각의 상기 멤버의 순서에 대응하는 값을 갖는 시스템.
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images