KR20060123026A

KR20060123026A - 타입이 정의되는 데이터베이스 저장소 외부에서 사용자정의 타입의 필드를 저장 및 검색하는 시스템 및 방법

Info

Publication number: KR20060123026A
Application number: KR1020057011387A
Authority: KR
Inventors: 라지브 비. 라잔; 발랜 세튜 라맨; 캉롱 얀
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-23
Filing date: 2004-07-29
Publication date: 2006-12-01
Also published as: US7284010B2; JP4838138B2; WO2005045706A1; EP1573601A4; US7765239B2; US20050203950A1; US7287039B2; JP2011034589A; JP2007509423A; CN100447780C; CN1735890A; US20080010285A1; JP5043175B2; KR101159378B1; US20050091255A1; EP1573601A1

Abstract

데이터베이스 저장소 내에 유지될 수 있는 객체의 타입이 사용자에 의해 정의된다. 타입 정의는 필드 및 동작을 포함하고, 각각의 필드는 개별 데이터 타입을 갖는다. 타입 정의의 하나 이상의 필드는 데이터베이스 외부에서 타입 정의의 다른 필드들로부터 분리되어 파일로서 저장될 타입의 데이터를 포함하는 것으로 지정될 수 있다. 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청이 수신될 때, 객체의 임의의 그렇게 지정된 필드 내의 데이터는 데이터베이스 저장소 외부의 파일에 바람직하게는, 데이터베이스 저장소가 구현된 컴퓨터의 파일 시스템 내에 저장된다. 객체의 다른 필드들 각각의 데이터는 보통의 방식으로 데이터베이스 저장소 내에 저장된다. 데이터베이스 저장소는 유지된 객체와, 데이터 저장소 외부에 파일로서 저장된 필드의 데이터 간의 링크 또는 참조를 유지한다. 어플리케이션은 컴퓨터의 파일 시스템을 통한, 주어진 필드의 데이터가 데이터베이스 저장소 외부에 저장되는 파일로의 "대역외" 액세스를 제공한다.

데이터베이스, 사용자 저의 타입, 객체

Description

타입이 정의되는 데이터베이스 저장소 외부에서 사용자 정의 타입의 필드를 저장 및 검색하는 시스템 및 방법{SYSTEM AND METHOD FOR STORING AND RETRIEVING A FIELD OF A USER DEFINED TYPE OUTSIDE OF A DATABASE STORE IN WHICH THE TYPE IS DEFINED}

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

본 출원은 2003년 10월 23일자 미국 출원번호 제10/692,227호에 대한 우선권을 주장하며, 그 명세서 전체는 참조에 의해 본원 명세서의 일부로서 포함된다.

<저작권 공지 및 사용허가권>

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

<본 발명의 분야>

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

마이크로소프트(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 <타입> Parse (SqlString s).

"데이터베이스 저장소의 객체 보존을 위한 시스템과 방법(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 필드의 값에 대한 직접적인 구조적 접근도 허용할 수 있다.

CLR 통합의 이점과 SQL SERVER에서 UDT의 준비를 취한 새 기술은, 계류중인, 일반적으로 양도된 특허 출원 일련 번호 10/646,646, 2003년 8월 21일 출원한, "편성, 탐색, 및 데이터 공유를 위한 저장 플랫폼(Storage Platform For Organizing, Searching, And Sharing Data)"으로 명명된 특허에서 설명한 저장 플랫폼이다, 참고로 그것의 공개를 본 명세서에 전부 편입하였다. 도 4는 본 건과 같이 현안중인 상기 출원에서 설명한 저장 플랫폼(300)의 아키텍처를 도시한 블록 도면이다. 저장 플랫폼을 때로는 "WinFS"로 일컫는다. 도 4에서, 저장 플랫폼(300)은 데이터베이스 엔진(314) 위에 구현된 데이터 저장소(302)을 포함한다. 한 실시예에서, 데이터베이스 엔진은 마이크로소프트 SQL SERVER 관계형 데이터베이스 엔진과 같은 관계형 데이터베이스 엔진을 포함한다.

데이터 저장소(302)는 Item과 Item간의 관계의 형태로, 뒤에 상세하게 설명되는 바와 같이, 데이터의 편성, 탐색, 공유, 동기, 및 보안을 지원하는 데이터 모델(304)을 구현한다. Item의 특정 타입은 스키마(340)와 같은 스키마에서 설명되고, 저장 플랫폼(300)은 이런 스키마를, 뒤에 상세하게 설명되는 바와 같이, 확장하기 위한 도구뿐만 아니라 이런 스키마를 배포하기 위한 도구(346)를 제공한다.

데이터 저장소(302) 안에서 구현된 변화 추적 메커니즘(306)은 데이터 저장소의 변화를 추적하는 능력을 제공한다. 데이터 저장소(302)도 보안 기능(308)과 프로모션/디모션(promotion/demotion) 기능(310)을 제공한다. 데이터 저장소(302)는 데이터 저장소(302)의 기능을 저장 플랫폼을 이용하는 다른 저장 플랫폼 컴포넌트와 응용 프로그램(예, 응용 프로그램 350a, 350b, 및 350c)에게 노출하는 응용 프로그램 인터페이스(Application Programming Interface, API)의 집합 또한 제공한다.

저장 플랫폼은 응용 프로그램 인터페이스(API)(322)를 더 포함하는데 그 API는 응용 프로그램(350a, 350b, 및 350c)과 같은 응용 프로그램으로 하여금 저장 플랫폼의 기능과 데이터베이스에 저장된 데이터의 접근을 가능케 한다. 저장 플랫폼 API(322)는 OLE DB API(324) 및 마이크로소프트 WINDOWS Win32 API(326)과 같은 다른 API와 함께 응용 프로그램에서 사용될 수 있다.

저장 플랫폼(300)은 사용자 또는 시스템 사이에 데이터의 공유를 용이하게 하는 동기화 서비스(330)를 포함하여 다양한 서비스(328)를 응용 프로그램에게도 제공한다. 예를 들어, 동기화 서비스(330)는 데이터 저장소(302)와 동일한 포맷을 갖춘 다른 데이터 저장소(360)와의 상호 운용성을 가능케 하고, 마찬가지로 다른 포맷을 갖춘 데이터 저장소(362)에 접근할 수 있다. 저장 플랫폼(300)은 WINDOWS NTFS 파일 시스템(318)과 같은 현존하는 파일 시스템과 데이터 저장소(302)의 상호 운용성을 허용하는 파일 시스템 기능도 제공한다.

적어도 몇몇의 실시예에서, 저장 플랫폼(300)은 응용 프로그램에게 데이터에 작용하는 것과 다른 시스템과의 상호 작용을 가능케 하는 추가 기능도 제공한다. 이런 기능들은 정보 대행 서비스(334)(Info Agent service), 통지 서비스(332)(notification service), 및 다른 유틸리티(336)의 형태와 같은 추가 서비스(328)의 형태로 구체화된다.

적어도 몇몇의 실시예에서, 저장 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템에, 또는 그 시스템의 통합 부분 형태로 구체화된다. 예를 들어, 제한을 두지 않으며, 본 발명의 저장 플랫폼은 운영 시스템, 가상 기계 관리자(virtual machine manager, VMM), 공통 언어 런타임(CLR) 혹은 이에 기능과 동등한 것, 또는 자바 가상 기계(Java Virtual Machine, JVM) 혹은 이에 기능과 동등한 것에, 또는 이들의 통합 부분 형태로 구체화된다.

저장 플랫폼의 공통 저장 기반, 및 타입적으로 기술된 데이터에 의하여, 저장 플랫폼은 수요자, 지식 연구자 및 기업에 대해 보다 효과적인 응용 프로그램 개발을 가능케 한다. 저장 플랫폼은 풍부하고 다양한 프로그램밍 외부 범위를 제공하여 데이터 모델에 고유 기능을 사용케 할 뿐만아니라 현존하는 파일 시스템과 데이터베이스 접근 메소드를 수용하여 확장하였다.

다음 설명에서, 다양한 특징 중에, 본 발명의 저장 플랫폼(300)을 "WinFS"라고 일컫는다. 그러나, 저장 플랫폼에 이 명칭을 사용하는 것은 단지 설명의 편의를 위한 것이며, 그 어떤 제한을 의도하는 것이 아니다.

WinFS 플랫폼의 데이터 모델은 Item, Item extension, Relationship 용어로 데이터 저장 단위를 정의한다. "Item"은 정보 저장의 기본 단위이다. 데이터 모델은 Item과 Item extension을 선언하고 Item간의 관계를 설립하는 메커니즘을 제공한다. Item은 복사(copy), 삭제(delete), 이동(move), 오픈(open), 및 등등과 같은 태스크를 사용해서 저장되고 검색되는 단위이다. Item은 현실 세계와 Contacts(연락), People(사람), Services(서비스), Locations(위치), Documents(모든 종류의 더큐먼트), 및 등과 같은 데이터의 판독 이해 가능 단위를 표시할 생각이다. Item extension은 현존하는 Item의 정의를 확장하는 방법이고, Relationship는 Item간의 링크 정의이다.

WinFS에서, 정보를 저장하기 위해 여러 가지 Item 타입이 정의된다. 예를 들어, Contacts, People, Locations, Documents, 등등에 대해 Item 타입이 정의되었다. 각각의 Item 타입은 정해진 Item의 특성과 특징을 정의하는 스키마로 설명된다. 예를 들어, "Location" Item은 EAddresses, MetropolitanRegion, Neighborhood, 및 PostalAddress과 같은 특성을 갖춘 것처럼 정의될 수 있다. 일단 정해진 Item 타입에 대해 스키마가 정의 되면, 스키마를 Item 타입의 대응되는 CLR 클래스 정의로 번역하기 배포 도구가 위해 사용되고, 이어서 데이터베이스 저장소에 WinFS Item 타입의 인스턴스가 보존되기 위해 CLR 클래스 정의에서(위에 설 명된 방법으로) UDT가 데이터베이스 저장소에 생성된다. WinFS API(322)를 사용해서, 응용 프로그램(예, 응용 프로그램 350a, 350b, 350c, 등)은 저장 플랫폼 데이터 저장소에 정보를 저장 및 검색하기 위해 데이터 저장소가 지원하는 Item 타입의 인스턴스를 생성할 수 있다. 데이터 저장소에 저장된 Item 타입의 각 인스턴스는 관련된 고유 식별자(예, Item_ID)를 갖는다; 한 실시예에서, 각 Item 식별자는 전역적으로 고유 식별자, 즉 "guid"이다. 이와 같이, WinFS 플랫폼은 데이터베이스의 CLR 통합과 UDT 기능을 이용해서 플렛폼에 정보 Item을 저장하는 것을 강화한다.

SQL SERVER에서 UDT의 어느 인스턴스와 같이, WinFS Item의 인스턴스는 결국 도 3에서 제시한 방법으로 데이터베이스 저장소 테이블에 저장된다. 응용 프로그램은 이윽고 데이터베이스 저장소에서 Item을 탐색 및 검색하기 위해 WinFS 플랫폼에 탐색 표준에 충족하는 쿼리를 제출한다. 도 5는 Item 타입 "Person"의 인스턴스를 검색하기 위해 데이터 저장소에 대해 쿼리가 어떻게 실행되는지를 제시한다. 단계(1)에서는, 응용 프로그램은 WinFS API(322)의 "FindAll" 메소드를 사용해서 특정 탐색 표준에 충족하는 모든 Item을 찾는 쿼리를 시작한다 - 이 경우는, Person 타입의 "Birthday" 필드의 값이 특정 날짜(예, 1999년12월31일)보다 큰 Person 타입의 모든 인스턴스이다. 단계(2)에서는, WinFS API(322)는 "FindALL" 태스크를 SQL 쿼리로 변환하여 하부 데이터베이스 엔진(예로, SQL SERVER)에 제출한다. 단계(3)에서는, 데이터베이스 엔진은 대응하는 Person UDT 인스턴스에 대해 쿼리를 실행하고 매칭되는 각 Person UDT 인스턴스의 저장된 값을 반환한다. 이 예에서, 단계(4)에서는, ADO.Net은 데이터베이스 저장소에서 반환된 비트들을 CLR객체로 변환(즉, 앞서 논의한 객체 수화 프로세스)하여 WinFS API(322)에 반환한다. ADO.Net은 Microsoft .NET Framework의 컴포넌트로서 SQL SERVER와 같은 데이터 소스에 CLR을 통해서 접근하는 관리된 코드를 제공한다. 이어서, WinFS API는 Person UDT 객체를 포장하여 Person 타입 Item으로 응용 프로그램에 반환한다.

데이터베이스 저장소에서 사용자 정의 타입(UDT)을 생성하는 능력은 강력한 능력이지만, 예를 들어, 디지털 이미지, 비디오, 오디오 등을 포함하는 큰 데이터 타입과 같은 특정 데이터 타입을 UDT의 정의된 필드로서 저장하기 위한 지원을 제공하는 능력을 강화시키는 것이 바람직할 수 있다. 또한, UDT의 큰 데이터 필드로의 "대역외(out of band)" 액세스를 제공하여, 그들이 데이터베이스 저장소의 기저 쿼리 언어를 사용하지 않고서 전형적인 파일 시스템 호출(오픈, 닫기 등)을 통해 액세스될 수 있도록 하는 것이 바람직할 것이다. 특히, 이들 능력은 상술된 WinFS 저장 플랫폼의 콘텍스트로 제공되는 것이 바람직할 것이다. 이제까지 이들 능력은 존재하지 않았다.

마이크로소프트 SQL SERVER 제품은 관계형 데이터베이스 테이블의 전체 컬럼을 FILESTREAM으로 불리는 타입으로서 지정하는 능력을 제공하여, 그 컬럼의 셀 내의 데이터가 관계형 데이터베이스 테이블과는 별도의 파일에 저장되도록 하지만, 사용자 정의 타입의 개별 필드를 이러한 방식으로 저장되도록 지정하는 능력은 없다.

IBM의 DB2 데이터베이스 제품은 파일에 대한 참조를 저장함으로써, 테이블 내의 컬럼을 파일 시스템 내의 파일에 링크시키는 능력을 지원하는 "데이터링크" 특징을 갖는다. 그러나, 그것은 단지 컬럼의 셀과 참조 파일 간에 N 대 1의 참조 모델만을 제공할 뿐이면서, 상술된 바와 같이, 셀과 파일 간에 1-1 모델을 필요로 한다. "데이터링크" 특징은 또한, (1) 프로그래밍 모델은 사용자 정의 타입 내부의 정규 관계형 데이터와 함께 별도의 파일의 균일한 저장 및 쿼리를 허용하지 않고, (2)DB2의 "데이터링크" 특징은 파일 시스템을 통해 참조된 파일에 저장된 컬럼 데이터의 업데이트를 허용하지 않는다는 추가적 이유로 불리하다.

오라클사의 "IFS" 제품은 중간층(middle tier) 소프트웨어를 사용하여, SMB, HTTP, FTP, SMTP 등과 같은 다수의 프로토콜을 통한 데이터로의 액세스를 제공한다. 데이터는 궁극적으로 데이터베이스에 저장된다. 오라클 IFS는 큰 데이터 타입을 포함한 상이한 타입의 데이터의 "통합" 뷰를 제공하지만, 관계형 데이터베이스 엔진과는 반대로 그 솔루션은 중간층 소프트웨어에서 구현되고, 이것은 상술된 필요성을 만족하지 못한다.

마지막으로, ISO/IEC 9075-9:2003(aka SQL 2003 MED)는 "데이터링크"를 새로운 데이터 타입으로서 제안한다. 제안된 표준에 따라, 데이터링크는 DATALINK 데이터 타입의 값이다. 데이터링크는 SQL-환경의 일부분이 아닌 임의의 파일을 참조한다. 파일은 임의의 외부 파일 관리자에 의해 관리되는 것으로 가정된다. 데이터링크는 개념적으로, 외부 파일에 대한 참조를 형성하는 문자 스트링으로 나타나고, 참조는 ISO/IEC 9075의 섹션에서 정의된 연산자를 호출함으로써 액세스가능해진다. 데이터링크 문자 집합이라고 불리는 참조의 문자 집합은 구현-정의된 것이 다. 이 제안된 표준은 상술된 바람직한 특징을 다루지 않는다.

따라서, 여전히, 예를 들어, 디지털 이미지, 비디오, 오디오 등을 포함하는 큰 데이터 타입과 같은 특정 데이터 타입을 사용자 정의 타입(UDT)의 정의된 필드로서 저장하기 위한 지원을 제공할 뿐만 아니라, 전형적인 파일 시스템 호출(오픈, 닫기 등)을 통해 그러한 큰 데이터 타입으로의 "대역외" 액세스를 제공하는 시스템 및 방법의 필요성이 존재한다. 본 발명은 이러한 필요성을 만족시킨다.

<본 발명의 요약>

본 발명은 예를 들어, 이미지, 비디오, 오디오 등을 포함하는 큰 데이터 타입과 같은 특정 데이터 타입을 데이터베이스 저장소 내에 사용자 정의 타입의 필드로서 저장하기 위한 시스템 및 방법에 관한 것이다. 본 발명에 따르면, 데이터베이스 저장소에 유지될 수 있는 객체의 타입은 사용자에 의해 정의된다. 타입 정의는 필드 및 동작을 포함하며, 각각의 필드는 개별 데이터 타입을 갖는다. 타입 정의의 하나 이상의 필드는 데이터베이스 저장소 외부의 파일로서 저장되고 타입 정의의 다른 필드로부터 분리되어 저장되는 타입의 데이터를 포함하는 것으로 지정될 수 있다. 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청이 수신될 때, 객체의 임의의 그렇게 지정된 필드 내의 데이터는, 바람직하게, 데이터베이스 저장소가 구현된 컴퓨터의 파일 시스템 내에서 데이터베이스 저장소 외부의 파일 내에 저장된다. 객체의 각각의 다른 필드 내의 데이터는 일반적인 방식으로 데이터베이스 저장소 내에 저장된다. 데이터베이스 저장소는 그 유지된 객체와, 데이터베이스 저장소 외부의 파일로서 저장되어 있는 필드의 데이터 간의 링크 또는 참조를 유지한다.

본 발명의 또다른 양태에 따르면, 어플리케이션은 컴퓨터의 파일 시스템을 통해, 주어진 필드의 데이터가 데이터베이스 저장소 외부에 저장되어 있는 파일로의 액세스를 제공받는다. 특히, 어플리케이션은 컴퓨터의 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스를 통해, 파일을 오픈하기 위한 호출을 생성할 수 있는데, 이 때, 호출은 데이터베이스 저장소 내의 객체의 필드의 아이덴티티에 의해 그 객체의 필드를 식별한다. 데이터베이스 저장소 내의 객체의 필드의 아이덴티티에 기초하여, 그 필드의 데이터를 포함하는 파일로의 파일 시스템 경로가 결정된다. 이 결정된 경로를 이용하여, 파일을 오픈하기 위한 호출을 실행한다.

따라서, 본 발명은 데이터베이스 저장소에 유지될 수 있는 객체의 사용자 정의 타입의 필드가 데이터베이스 저장소 외부에서의 저장을 위해 즉, 데이터 저장소가 구현되는 컴퓨터의 파일 시스템 내에 파일로서 지정될 수 있게 한다. 또한, 사용자 정의 타입의 그 필드의 데이터를 포함하는 파일로의 액세스는 컴퓨터의 파일 시스템을 통해 제공된다.

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

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

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

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

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

도 4는 본 발명의 특징의 이점을 취한 예시적인 저장 플랫폼(platform)을 설명하는 블록 도면.

도 5는 도 4에서 설명한 저장 플랫폼의 콘텍스트(context)로 보존된 사용자 정의 타입 객체에 대해 쿼리를 실행하는 프로세스를 설명하는 도면.

도 6은 "Person"이라고 불리는 사용자 정의 타입에 대한 관리된 코드 클래스 정의를 도시하는 예시적이고 부분적인 코드 세그먼트를 도시.

도 7은 본 발명의 시스템 및 방법의 일 실시예를 도시하는 도면.

도 8은 본 발명의 또 다른 양태의 실시예에 따라, 사용자 정의 타입의 인스턴스의 필드의 데이터를 포함하는 파일로의 "대역외" 액세스의 시스템 및 방법을 도시하는 블록도.

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

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

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

상술된 바와 같이, 본 발명은 예를 들어, 디지털 이미지, 비디오, 오디오 등을 포함하는 큰 데이터 타입과 같은 특정 데이터 타입을 데이터베이스 저장소 내에 사용자 정의 타입의 필드로서 저장하는 방법에 관한 것이다. 본 발명에 따르면, 데이터베이스 저장소 내에 유지될 수 있는 객체의 타입은 사용자에 의해 정의된다. 타입 정의는 필드 및 동작을 포함하며, 이 각각의 필드는 개별 데이터 타입을 갖는다. 타입 정의의 하나 이상의 필드는 데이터베이스 저장소 외부의에 일로서 저장되고 타입 정의의 다른 필드로부터 분리되어 저장되는 타입의 데이터를 포함하는 것으로서 지정될 수 있다. 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청이 수신될 때, 객체의 임의의 그렇게 지정된 필드 내의 데이터는 데이터베이스 저장소 외부의 파일 내에, 바람직하게는, 데이터베이스 저장소가 구현된 컴퓨터의 파일 시스템 내에 저장된다. 객체의 각각의 다른 필드 내의 데이터는 일반적인 방식으로 데이터베이스 저장소 내에 저장된다. 데이터베이스 저장소는 유지된 객체와, 데이터베이스 저장소 외부에 파일로서 저장된 필드의 데이터 간의 링크 또는 참조를 유지한다.

도 6은 사용자 정의 타입의 정의의 예시적이고 부분적인 코드 리스팅이며, 본 발명의 일 실시예에 따라, 타입의 인스턴스가 데이터베이스 저장소에 유지될 때 타입의 필드를 데이터베이스 저장소의 외부에 저장되는 필드로서 지정하는 것을 나타낸다. 특히, "Person"이라고 불리는 사용자 정의 타입에 대한 CLR 클래스가 도시된다. 그 구문은 본 발명의 배경기술에서 설명된 바와 같이, SQL SERVER 데이터베이스 엔진에 의해 사용되는 구문이다. 그러나, 본 발명은 SQL SERVER 데이터베이스 엔진으로 사용하는 것으로 제한되지 않으며, 오히려, 사용자 정의 타입을 지원하는 임의의 데이터베이스 관리 시스템의 콘텍스트에서 사용될 수 있음을 유념한다.

도 6에 도시된 CLR 클래스는 Person 타입에 대해 2개의 필드를 정의한다. 그 중, "FirstName"이라고 불리는 필드는 데이터 타입 SqlString을 갖는 것으로 정의되고, "PhotoFS"라고 불리는 필드는 데이터 타입 SqlBytes를 갖는 것으로 정의된다. SQL SERVER에서 사용자 정의 타입에 대한 완전한 CLR 클래스 정의는 (도 1의 예시적인 코드 리스팅에서 도시된 바와 같이) 본 배경기술 섹션에서 설명된 요구조건에 따라, 추가 필드 및 방법을 가진다는 것을 이해해야 한다. PhotoFS 데이터 필드는 예를 들어, 이 타입의 인스턴스가 나타낼 수 있는 Person의 사진을 포함하 는 이미지 데이터를 보유할 수 있다. 그러한 데이터는 본 발명이 이롭게 적용될 수 있는 큰 데이터 타입의 타입의 예이다.

본 발명에 따라, 이 예에서, Person 타입의 PhotoFS 필드는 그 타입의 인스턴스가 저장소에 유지될 때, 데이터베이스 저장소의 외부에 저장되는 필드로서 지정된다. 특히, 본 실시예에서, 이것은 그 지정을 제공하는 커스텀 속성을 갖는 UDT의 CLR 클래스 정의의 필드에 주석함으로써 성취된다. 특히, 본 발명의 배경기술에서 설명된 SqlUdtField() 커스텀 속성의 새로운 속성이 생성되었다. 새로운 속성은 "IsFilestream"이라고 불린다. 속성에 대한 "참" 값(예를 들어, IsFilestream = true)은 Person 타입의 이 필드가 본 발명에 따라 데이터베이스 저장소 외부의 파일로서 저장되어야 한다는 것을 나타낸다. 그러나, 필드가 그렇게 지정되는 특정 방법이 이 예시적인 메커니즘으로 제한되지 않음을 이해해야 한다. 오히려, 기저 데이터베이스 시스템에 의해 인식될 수 있는 사용자 정의 타입의 정의에 대한 임의의 형태의 주석이 채용될 수 있다. SqlUDTField() 커스텀 속성의 IsFilestream 속성을 포함하는 사용자 정의 타입의 필드에 대한 주석은 정의된 타입에 관련된 메타데이터 집합을 정의한다.

본 실시예에서, IsFilestream 속성은 타입 SqlBytes의 필드에만 적용될 수 있다. 그러나, 다른 실시예에서, 상술된 바와 같이, 이 속성은 다른 데이터 타입의 필드에 적용될 수 있다.

또한, 본 발명에 따라, UDT에 대한 CLR 클래스가 컴파일되고 예를 들어, 상술된 T-SQL 스크립트 커맨드 CREATE TABLE을 이용하여 데이터베이스 서버에 등록될 때, 데이터베이스 엔진은 데이터베이스 저장소 내의 UDT의 인스턴스의 필드의 구조적 레이아웃의 인식을 유지하기 위하여, 시스템 카탈로그 내의 타입 정의에 대한 주석으로부터 유도된 메타데이터를 저장한다. 특히, 이 메타데이터는 IsFilestream=true 속성으로 주석된 임의의 필드를 반영할 것이다.

도 7을 참조하면, 데이터베이스 저장소 내의 테이블의 예시적인 로우(600)가 도시되어 있다. 이 테이블은 예를 들어, 도 6에 도시된 CLR 클래스에 의해 정의된 Person UDT의 인스턴스를 저장하는 데 사용될 수 있다. 테이블은 테이블 내의 특정 로우에 대한 고유 식별자(즉, "row_guid")를 포함하는 컬럼(604), UDT의 인스턴스에 관련된 식별자(예를 들어, WinFS Item 타입의 인스턴스에 관련된 Item_ID)를 포함하는 컬럼(605), 및 UDT의 인스턴스의 필드의 실제 직렬화된 값을 포함하는 컬럼(602)을 포함한다. 다른 컬럼 외에, 테이블은 전형적인 SQL SERVER FILESTREAM 데이터를 보유하도록 정의된 컬럼(606)을 포함할 수 있다.

테이블의 이 로우의 UDT 컬럼(602)을 차지하는 UDT의 인스턴스의 직렬화된 데이터(즉, 필드의 값)는 일련의 프레그먼트(608)에 정렬된다. 본 실시예에서, 이 프레그먼트의 레이아웃은, 상술된 바와 같이 UDT의 필드 및 동작데 주석된 SqlUdtField() 및 SqlUdtProperty() 속성에 의해 제어된다.

본 실시예에서, 데이터베이스 저장소 외부의 UDT의 직렬화된 데이터의 나머지로부터 분리되어 저장되어야 하는 것으로서 지정된 UDT의 각각의 필드는, UDT의 저장된 레이아웃 내의 별도의 프레그먼트를 할당받는다. 예를 들어, UDT의 2개의 필드가 그렇게 지정되면, 이 필드는 각각 프레그먼트(612 및 614)로서 할당받을 수 있다. 또한, 본 실시예에서, 그러한 프레그먼트는 각각 고유 식별자, 예를 들어, 프레그먼트 ID(610)를 할당받는다. 예를 들어, 프레그먼트(612)는 프레그먼트 ID "xx"를 할당받을 수 있는 반면, 프레그먼트(614)는 프레그먼트 ID "yy"를 할당받을 수 있다. 단지 설명의 편이를 위해, 본 발명에 따라 데이터베이스 저장소 외부의 파일로서 UDT의 다른 필드들로부터 분리되어 저장되어야 하는 것으로서 지정된 UDT의 필드는, 이하, UDT의 "Filestream 필드"로서 지칭될 것이다. 그러한 참조는 임의의 방식으로 제한되는 것으로 의도되지 않는다.

또한, 본 발명에 따르면, 데이터베이스 저장소의 테이블 내의 할당된 프레그먼트에 UDT의 인스턴스의 필드 각각의 데이터를 저장하는 것 대신에, 그러한 필드의 데이터는 데이터 저장소 외부에서, 그 데이터베이스 저장소가 구현된 컴퓨터의 파일 시스템 내의 파일 내에 저장된다. 본 실시예에서, 프레그먼트는 파일에 대한 참조만을 저장하며, 참조는 파일에 대한 링크를 정의한다. 예를 들어, 프레그먼트(612)를 할당받은 필드에 대한 데이터는 파일(616)에 대신 저장된다. 프레그먼트는 화살표(620)가 나타내는 바와 같이, 파일 시스템 내의 파일(616)의 위치에 대한 참조를 포함한다. 마찬가지로, 프레그먼트(614)를 할당받은 필드에 대한 데이터는 파일(618)에 대신 저장된다. 다시, 프레그먼트(614)는 화살표(622)가 나타내는 바와 같이 파일에 대한 참조를 포함한다. 임의의 개수의 필드가 이러한 방식으로 지정될 수 있고, 각각의 그러한 필드에 대한 데이터는 이러한 방식으로 파일 시스템 디렉토리 내의 각각의 파일에 저장될 것이다.

본 실시예에서, 각각의 UDT는 컴퓨터 파일 시스템 내의 상이한 컬럼-레벨의 디렉토리를 지정받는다. 주어진 UDT의 인스턴스의 Filestream 필드의 데이터를 포함하는 파일에 대한 명명 규칙은 [row_guid].[fragment_ID]이다. 도시된 예에서, Person UDT의 인스턴스의 직렬화된 데이터는 "AABB"의 row_guid를 할당받은 테이블의 로우 내에 저장된다. 프레그먼트(612)는 프레그먼트 ID "xx"를 할당받고, 프레그먼트(614)는 프레그먼트 ID "yy"를 할당받는다. 따라서, 프레그먼트(612)에 의해 참조된 파일에 대한 파일이름은 "AABB.xx"이지만, 프레그먼트(614)에 의해 참조된 파일에 대한 파일이름은 "AABB.yy"이다.

UDT의 인스턴스의 대응하는 Filestream 필드에 대한 데이터가 데이터베이스 저장소 외부의 파일로서 저장되더라도, 마치 데이터베이스 테이블 내에 저장되어 있는 것처럼 데이터베이스 엔진의 동작에 영향을 받는다는 것을 유념해야 한다. 예를 들어, SQL SERVER 데이터베이스 엔진에서 구현된 바와 같이, T-SQL 커맨드 INSERT 및 UPDATE는 데이터 필드가 데이터베이스 테이블 내에 저장되어 있는 것처럼, UDT의 인스턴스의 Filestream 필드의 데이터를 저장하는 파일에 새로운 데이터를 삽입하거나 기존 데이터를 업데이트하는 데 사용될 수 있다. 마찬가지로, T-SQL DELETE 커맨드는 별도의 파일에 저장된 하나 이상의 Filestream 필드를 갖는 UDT를 포함하는 로우를 삭제하는 데 사용될 수 있다. 로우를 삭제하는 것은 참조된 파일도 삭제한다. 별도의 파일 내에 저장되어 있는 UDT의 Filestream 필드는 또한, 임의의 다른 컬럼과 같이 쿼리될 수 있다.

도 7에 도시되어 있는 바와 같이, 상술된 본 발명의 방법은 또한, SQL SERVER에 제공된 통상적인 FILESTREAM 컬럼 타입과 함께 공존할 수 있다. 예를 들 어, 도 7에 도시된 바와 같이, 테이블의 컬럼(606)은 타입 "FILESTREAM"(FS)으로서 정의될 수 있다. 컬럼이 타입 "FILESTREAM"으로서 정의될 때, 그 컬럼의 주어진 셀 내의 데이터는 테이블의 그 컬럼에 관련된 컬럼-레벨의 디렉토리 내의 별도의 파일에 저장된다. 본 발명은 데이터베이스 저장소 외부의 별도의 파일에 UDT 객체의 개별 필드의 데이터를 저장하는 능력을 제공함으로써 이 능력에 따라 개선된다는 것을 이해할 것이다.

본 발명에 따라 별도의 파일에 저장된 UDT 객체의 Filestream 필드의 데이터는 2가지 방법으로 검색될 수 있다. 첫째로, 상술된 바와 같이, 데이터는 통상적인 T-SQL 쿼리를 사용하여 액세스될 수 있다. 예를 들어, (도 6에 정의된) Person 타입의 인스턴스가 저장되어 있는 테이블을 "Person-sql"이라 하고, Person UDT의 인스턴스의 직렬화된 데이터를 포함하는 컬럼(602)을 "Person_col"이라 한다고 가정하자. 다음의 쿼리는 인스턴스의 PhotoFS라 불리는 필드의 데이터를 반환할 것이고, 이것은 본 발명에 따라 별도의 파일로서 저장된 것이다.

SELECT Person_col.PhotoFS FROM Person_SQL WHERE FirstName = "Steve"

데이터베이스 엔진은 이러한 쿼리를 수신할 때, Person 타입의 인스턴스의 PhotoFS 필드가 저장되어 있는 파일로의 파일 시스템 경로 이름을 획득한다. 경로 이름은 쿼리를 만족하는 Person UDT 객체의 대응하는 프레그먼트로부터 획득된다. 물론, Person UDT의 복수의 객체가 그러한 쿼리를 만족할 수 있다. 쿼리를 만족하는 각각의 객체에 대하여, 데이터베이스 엔진은 PhotoFS 필드의 데이터를 포함하는 파일의 확득된 경로 이름을 사용하여 파일 시스템의 어플리케이션 프로그래밍 인터 페이스에 대한 적절한 호출(예를 들어, Win32 API 내의 CreateFile)을 할 것이다. 그 후, 데이터베이스 엔진은 그 파일을 판독하고 데이터를 어플리케이션에 반환하고 파일을 닫을 것이다.

본 발명의 또 다른 양태에 따라, 어플리케이션은 또한, 컴퓨터의 파일 시스템을 통해 그러한 파일에 직접적으로 액세스할 수 있다. 특히, 어플리케이션은 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스를 통해 그러한 파일을 직접적으로 열기 위한 호출을 생성할 수 있다. 호출은 데이터베이스 저장소 내의 그 아이덴티티를 식별함으로써 객체의 대응하는 Filestream 필드를 식별할 것이다. 데이터베이스 저장소 내의 객체의 필드의 아이덴티티에 기초하여, 그 필드의 데이터를 포함하는 파일로의 파일 시스템 경로가 결정된다. 파일을 오픈하기 위한 호출은 결정된 경로를 사용하여 실행된다.

본 발명의 이러한 양태의 실시예는 도 8에 도시되어 있다. 이 예에서, 본 발명의 이러한 양태는 배경기술 섹션에서 설명된 WinFS 저장 플랫폼의 콘텍스트에서 구현된다. 그러한 능력은 특히, WinFS 플랫폼에 이롭다. 그러나, 본 발명의 이러한 양태는 사용자 정의 타입의 인스턴스의 필드의 데이터를 포함하는 파일로의 직접적인 액세스가 필요한 임의의 환경에서 구현될 수 있음을 이해해야 한다.

도 8을 참조하면, 본 발명에 따라, 클라이언트 어플리케이션(800)은 사용자 정의 타입의 인스턴스의 Filestream 필드의 데이터를 포함하는 파일로의 직접적인 액세스를 요구할 수 있으며, 이 때, 필드는 WinFS 저장 플랫폼(808)이 구현되어 있는 컴퓨터 시스템의 파일 시스템(804) 내의 파일에 저장된 것이다. 상술된 바와 같이, WinFS 저장 플랫폼은 SQL SERVER 데이터베이스 엔진과 같은 데이터베이스 엔진(810) 상에서 구현된다.

본 발명의 이러한 또다른 양태에 따르면, WinFS API를 사용하여 데이터베이스 저장소(도시되지 않음) 내에 UDT 객체로서 유지된 WinFS Item의 필드에 액세스할 수 있는 클라이언트 어플리케이션이 대신에, 파일 시스템(804)의 어플리케이션 프로그래밍 인터페이스(802)를 통해, 파일 시스템(804)에서 별도로 저장되어 있는 Item(즉, UDT)의 Filestream 필드로의 직접적인 액세스를 요청할 수 있다. 도 8에 도시된 예시적인 실시예에서, 클라이언트 어플리케이션은 단계(1)에서, Win32 API의 CreateFile 인터페이스를 호출함으로써 이 프로세스를 개시하여, 유지된 Item(UDT)의 인스턴스 내의 대응하는 필드의 아이덴티티에 기초하여 경로 이름을 요청된 데이터를 식별하는 Win32 API에 전달한다. 예를 들어, WinFS 명명 규칙에 따라, (상술된 본 발명에 따라 파일 시스템 내의 파일에 분리되어 저장될 수 있는 것을 포함하여) 데이터베이스 저장소 내의 Item의 필드를 식별하는 경로 이름은 다음의 형태를 가질 수 있다.

＼＼?＼UNC＼machinename＼sharename＼Item_IdValue＼[typename].fieldname.(locator).[typename].fieldname

그러나, 이 포맷은 단지 예시적인 것이며, 다른 실시예에서는 본 발명의 범주를 벗어나지 않고서 실제 구획문자 및 포맷dl 다를 수 있음을 이해해야 한다.

상기 예시적인 포맷을 참조하여, 경로 이름 포맷의 처음 부분은 다음과 같이 시작한다.

＼＼?＼UNC＼machinename＼defaultstore＼...

이 때, machinename은 WinFS 플랫폼이 실행되는 기계의 이름이고, defaultstore는 Item의 인스턴스가 저장되어 있는 데이터베이스의 루트에 관련된 공유 이름이다. WinFS는 복수의 데이터베이스 저장소를 지원하기 때문에, defaultstore는 특정 데이터베이스에 관련된 공유로, 또는 데이터베이스의 일부분에 관련된 공유로 대체될 것이다. 경로의 ...＼＼?＼UNC＼... 부분은, 정상적인 경로 이름이 받는 256 바이트(등)의 한정으로 제한되도록 하기 보다, 경로를 보유하는 스트링의 길이를 32KB까지 허용하는 데 사용된다. 경로 이름은 이러한 포맷으로 작용하기 위해 유니코드이어야 한다. 따라서, 경로 이름의 이 부분은 특정 기계에 대한 특정 데이터베이스/공유로의 방향을 제공한다.

경로 이름의 다음 부분(...＼Item_IdValue...)은 객체의 타입을 "Item"으로서 식별하고, 포함된 객체(들)의 Item_ID 값(들)이 후속한다. 본 발명은 또한, Item 확장 및 관계도 WinFS 데이터베이스 저장소 내의 UDT에 맵핑되기 때문에, WinFS 내의 Item 확장 및 관계에 적용될 수 있음을 유념한다. Item 확장의 경우에, 경로 이름의 이 부분은 (...＼Extension_IdValue...)로 대체될 것이다. 관계의 경우에, 경로 이름의 이 부분은 (...＼Relationship_IdValue...)로 대체될 것이다.

경로 이름의 마지막 부분 ...＼[typename].fieldname.(locator).[typename].fieldname은 호출의 대상이 되는 Item, Item 확장, 또는 관계 UDT의 특정 필드를 식별한다. 이것은 반복된 typename-fieldname-locator 트리플을 포함한다. typename은 각괄호 []에 포함되고, locator는 존재한다면 괄호에 포함된다. typename은 필드의 타입의 이름, 또는 객체 루트의 타입의 이름이다. fieldname은 필드의 이름이다. 그리고, 필드가 어레이 또는 컬렉션과 같이 복수의 인스턴스를 갖는 경우, locator는 그 필드 내의 어느 Item인지를 나타낸다. UDT는 객체의 중첩된 레벨을 포함하는 경우, 추가적인 typename-fieldname-locator 트리플이 필드 내의 필드를 지정하는 데 제공되고, 결국 IsFrilestream = true 속성을 갖는 필드에서 정지할 것이다.

도 6 및 7의 예를 계속하면, Person UDT의 인스턴스의 PhotoFS 필드로의 경로 이름은 ＼＼?＼UNC＼localhost＼defaultstore＼ItemID＼Person.PhotoFS로서 지정될 수 있다. 이 때, ItemID는 Person 타입의 특정 인스턴스에 지정된 전역적으로 고유 식별자(guid)이다.

데이터베이스 저장소 외부의 별도의 파일로서 유지된 Item의 Filestream 필드에 대한 WinFS 경로 이름은 컴퓨터 파일 시스템에 의해 적절히 분해될 수 없기 때문에, 본 발명에 따라, 동등한 파일 시스템 경로 이름으로 번역된다. 본 실시예에서, 이 프로세스는 "FS 에이전트"라고 불리는 소프트웨어 컴포넌트에 의해 개시된다. 물론, 다른 실시예에서는, 다른 소프트웨어 컴포넌트가 이 기능을 수행하는 데 사용될 수 있다. 단계(2)에서 도시되는 바와 같이, 파일 시스템 API(802)는 WinFS 경로 이름을 포함하는 클라이언트 어플리케이션으로부터 CreateFile 커맨드를 수신할 때, 그것을 예를 들어, WinFS 경로 이름의 "machinename/defaultstore" 부분으로부터인 것으로 인식한다. 이 경로 이름과 함께 수신된 모든 파일 요청은 FS 에이전트에 전달된다.

단계(3)에서, FS 에이전트는 WinFS API(808)에게 "OPEN" 호출을 발행하고, Item 필드의 WinFS 경로 이름을 전달한다. 단계(4)에서, WinFS 플랫폼은 WinFS 경로 이름으로부터 Item 및 필드를 식별하고, 이 정보를 GetPathName() 요청으로 데이터베이스 엔진에 전달한다. GetPathName()은 상술된 방식으로 데이터베이스 저장소로부터 분리되어 저장되어 있는 UDT 객체의 Filestream 필드에 대한 Win32 파일 시스템 경로이름을 반환하는 데이터베이스 엔진 함수이다. WinFS 플랫폼은 또한, Item의 필드로의 액세스에 대해 임의의 보안 제약을 시행한다.

단계(5)에서, 데이터베이스 엔진은 요청의 대상이 되는 UDT 객체가 저장되어 있는 데이블에서 테이블 검색을 수행함으로써 GetPathName() 요청에 응답한다. 데이터베이스 엔진은 테이블의 정확한 로우에 위치를 정한 후, 그 로우 내의 UDT 객체의 직렬화된 프레그먼트에 위치를 정한다. 질문 내의 Filestream 필드에 대하여, 데이터베이스 엔진은 그 필드에 대한 데이터가 저장되어 있는 파일로의 실제 파일 시스템 경로를 그 대응하는 프레그먼트로부터 추출한다. 데이터베이스 엔진은 실제 경로를 WinFS API(808)에 다시 송신한다. 단계(6)에서, WinFS는 파일 시스템 경로를 FS 에이전트(806)에 다시 전달하고, 단계(7)에서, FS 에이전트는 파일 시스템 API(802)를 호출하여 파일을 열고, 요청 내의 실제 파일 시스템 경로를 전달한다. 단계(8)에서, 파일 시스템 API(802)에 대해 CreateFile 호출이 이루어질 때 보통 이루어지는 바와 같이, 파일 시스템 API(802)는 파일에 대한 핸들을 획득하고 그것을 클라이언트에 다시 전달한다{단계(9)}.

이 점에서, 클라이언트 어플리케이션(800)은 정상 파일 시스템 API 호출(예를 들면, Win32 API 파일 I/O 호출)을 통해 파일을 판독하고 파일에 기록할 수 있다. 클라이언트 어플리케이션(800)은 파일과 함께 종료될 때 파일 시스템 API에 CLOSE 호출을 발행한다. 다시, FS 에이전트(806)가 이 호출을 가로챈다. FS 에이전트(806)는 "CLOSE' 호출을 WinFS API(808)에 발행하여 파일이 닫혀지는 것을 요청한다. WinFS 플랫폼(808)은 이 동작을 유지된 Item에 대한 업데이트로서 모델링하고, 임의의 관련된 변경 추적 및 업데이트에 관련된 다른 기능을 수행한다. 데이터베이스 엔진은 유지된 UDT 객체에 대해 자신의 업데이트 프로세싱을 수행한다. 이 프로세싱이 완료되면, 제어는 FS 에이전트(806)로 되돌아가고, FS 에이전트는 파일 시스템 API(802)을 호출하여 클라이언트 어플리케이션(800) 도중에 그 정상 파일 닫기 동작을 수행한다.

따라서, 상술된 방법을 통해, 클라이언트 어플리케이션은 유지된 UDT의 Filestream 필드로의 "대역외" 액세스를 가지고 있고, 그 필드는 데이터베이스 관리 시스템이 구현되어 있는 컴퓨터의 파일 시스템 내에 별도의 파일로서 저장되어 있다.

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

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

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

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

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

도 9는 예시적인 네트워크 또는 분산 컴퓨팅 환경의 개념 도면을 제시한다. 분산 컴퓨팅 환경은 컴퓨팅 객체(10a, 10b, 등) 및 컴퓨팅 객체 혹은 장치(110a, 110b, 110c, 등)를 포함한다. 이들 객체는 프로그램, 메소드, 데이터 저장소, 프로그램 가능 논리, 등을 포함한다. 객체는 PDA, 텔레비전, MP3 플레이어, 개인 컴퓨터, 등과 같은 동일한 또는 다른 장치들의 부분을 포함할 수 있다. 각 객체는 통신 네트워크(14)를 통해 다른 객체와 통신할 수 있다. 이 네트워크 자체는 도 9 의 시스템에 서비스를 제공하는 다른 컴퓨팅 객체와 컴퓨팅 장치를 포함하며, 다중 상호연결된 네트워크를 나타낸다. 본 발명의 관점과 일치하여, 각 객체(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)를 가능케 한다. "클라이언트"는 아무 관계없는 다른 클래스 또는 그룹의 서비스를 사용하는 다수의 클래스 또는 그룹이다. 그러므로, 컴퓨팅에서, 클라이언트는 프로세스이다. 즉, 대략적으로 다른 프로그램에 의해 제공되는 서비스를 요청하는 명령문 또는 태스크의 집합이다. 클라이언트 프로세스는 다른 프로그램 또는 서비스 자체에 관한 처리 세부 사항을 알 필요 없이 요청된 서비스를 이용한다. 클라이언트/서버 아키텍처에서, 특히 네트워크 시스템에서, 클라이언트는 일반적으로 다른 컴퓨터, 즉, 서버에 의해 제공되는 공유된 네트워크 자원을 접근하는 컴퓨터이다. 비록 상황에 따라서, 어느 컴퓨터도 클라이언트, 서버, 또는 둘 다 겸한 것으로 간주할 수 있지만, 도 9의 예에서, 컴퓨터(110a, 110b, 등)는 클라이언트로 생각할 수 있고, 컴퓨터(10a, 10b, 등)는 서버로 생각할 수 있다. 이런 컴퓨팅 장치의 어느 것이든 본 발명의 객체 보존 기술을 내포한 방식으로 데이터를 처리할 수 있다.

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

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

도 9는 서버가 네트워크/버스를 통해 클라이언트 컴퓨터와 통신하며, 본 발명이 이용될 수 있는 예시적인 네트워크 또는 분산 환경을 나타내고 있다. 네트워크/버스(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)을 갖춘 컴퓨터 네트워크 환경에 이용된다.

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

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

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

도 10에서, 본 발명을 구현하는 예시적인 시스템은 컴퓨터(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)에 의해 즉시 액세스 가능하고 및/또는 조작되는 데이터 및/또는 프로그램 모듈을 포함한다. 한 예로서, 도 10은 운영 시스템(134), 응용프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.

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

앞에서 논의하고, 또한 도 10에서 도시된 드라이브와 관련된 컴퓨터 저장 매체는 컴퓨터(110)에게 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장 장소를 제공한다. 예로, 도 10에서 하드 디스크 드라이브(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)일수도 있고, 비록 도 10에서 메모리 저장 장치(181)만 도시했으나, 전형적으로 컴퓨터(110)에 관해 위에 언급한 여러 혹은 모든 요소를 포함한다. 도 10에서 묘사한 논리적 연결은 LAN(171)과 WAN(173)을 포함한다. 그러나 다른 네트워크/버스도 포함할 수 있다. 이러한 네트워킹 환경은 사무실, 기업체 전반 컴퓨터 네트워크, 인트라넷 및 인터넷에서 보편적으로 존재한다.

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

상술된 바와 같이, 본 발명은 데이터베이스 저장소가 구현된 컴퓨터의 파일 시스템 내에 별도의 파일로서 데이터베이스 저장소의 외부에서, 데이터베이스 저장소에 유지되는 사용자 정의 타입의 인스턴스의 필드를 저장 및 검색하는 시스템 및 방법에 관한 것이다. 본 발명은 특히, 큰 데이터 타입을 데이터베이스 관리 시스템 내의 사용자 정의 타입의 필드로서 저장하는 데 유리하다. 포괄적인 본 발명의 개념으로부터 벗어나지 않고서, 상술된 실시예에 대한 변경이 이루어질 수 있음을 이해해야 한다. 예를 들어, 본 발명의 실시예가 마이크로소프트의 SQL SERVER 데이터베이스 관리 시스템에서 구현되는 것으로서 상술되었지만, 본 발명은 사용자 정의 타입의 생성을 지원하는 임의의 데이터베이스 관리 시스템에서 구현될 수 있음을 이해해야 한다. 또한, 본 발명의 특정 양태는 상술된 WinFS 저장 플랫폼의 콘텍스트에서 구현되는 것으로 설명되었지만, 본 발명의 그러한 양태는 그러한 환 경에서의 구현으로 제한되지 않는다. 오히려, 본 발명의 방법 및 시스템은 사용자 정의 타입의 인스턴스의 필드의 저장 및 검색이 바람직한 임의의 시스템에서 구현될 수 있다. 따라서, 본 발명은 개시된 특정 구현으로 제한되지 않고, 첨부 청구범위에 의해 정의된 본 발명의 취지 및 범주 내에 있는 모든 변경을 포함하는 것으로 의도된다.

Claims

사용자 정의 타입의 인스터스인 객체가 데이터베이스 저장소에 유지될 수 있는 시스템 - 상기 사용자 정의 타입의 정의는 하나 이상의 필드 및 동작을 포함하고, 상기 필드 각각은 개별 데이터 타입을 갖고, 상기 정의의 상기 필드들 중 적어도 하나는 상기 타입 정의의 다른 필드들로부터 분리되어 상기 데이터베이스 저장소 외부에 파일로서 저장되는 타입의 데이터를 포함하는 것으로 지정됨 - 에서,

상기 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청을 수신하는 단계;

상기 객체의 상기 인스턴스의 상기 적어도 하나의 지정된 필드 내의 데이터를 상기 데이터베이스 저장소 외부에 파일로서 저장하는 단계; 및

상기 객체의 상기 인스턴스의 다른 필드들 각각의 데이터를 상기 데이터베이스 저장소 내에 저장하는 단계

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

상기 데이터베이스 저장소 내에 저장되는 상기 객체의 필드들의 데이터와 상기 데이터베이스 저장소 외부에 파일로서 저장되는 필드의 데이터 간의 링크를 제공하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터는 상기 데이터베이스의 테이블의 컬럼 내의 프레그먼트(fragment)로서 저장되고, 상기 컬럼은 상기 사용자 정의 타입으로서 지정되는 방법.
제3항에 있어서,

상기 객체에 관련된 고유 식별자가 상기 객체의 필드들의 데이터와 동일한 로우에 있는 상기 테이블의 또 다른 컬럼에 저장되는 방법.
제1항에 있어서,

상기 객체의 상기 적어도 하나의 지정된 필드의 데이터는 상기 데이터베이스 서버가 실행되고 있는 컴퓨터의 파일 시스템의 소정의 디렉토리 내에 파일로서 저장되는 방법.
제5항에 있어서,

상기 컴퓨터의 파일 시스템을 통해, 상기 적어도 하나의 필드의 데이터가 상기 데이터베이스 저장소 외부에 저장되어 있는 상기 파일로의 어플리케이션에 의한 액세스를 제공하는 단계를 더 포함하는 방법.
제6항에 있어서,

상기 적어도 하나의 필드의 데이터가 저장되어 있는 파일로의 어플리케이션에 의한 액세스를 제공하는 단계는,

상기 컴퓨터의 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스를 통해 상기 어플리케이션으로부터 상기 파일을 오픈하기 위한 호출을 수신하는 단계 - 상기 호출은 상기 데이터베이스 저장소 내의 상기 객체의 필드의 아이덴티티에 의해 상기 객체의 필드를 식별함 - ;

상기 데이터베이스 저장소 내의 상기 객체의 필드의 아이덴티티로부터, 상기 객체의 상기 필드의 데이터를 포함하는 상기 파일로의 상기 컴퓨터의 파일 시스템 내의 경로를 결정하는 단계; 및

상기 결정된 경로를 이용하여, 상기 파일을 오픈하기 위한 호출을 실행하는 단계

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

상기 컴퓨터의 파일 시스템은 마이크로소프트 NTFS 파일 시스템을 포함하고, 상기 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스는 Win32 어플리케이션 프로그래밍 인터페이스를 포함하는 방법.
제1항에 있어서,

상기 객체의 타입은 관리된 코드의 클래스로서 정의되는 방법.
컴퓨터의 데이터베이스 저장소에 데이터를 저장하기 위한 방법으로서,

상기 데이터베이스 저장소에 유지될 수 있는 객체의 타입을 정의하는 단계 - 상기 타입 정의는 필드 및 동작을 포함하고, 상기 필드 각각은 개별 데이터 타입을 가짐 - ; 및

상기 타입 정의의 필드들 중 적어도 하나를, 저장되고 상기 타입 정의의 다른 필드들로부터 분리되어 상기 데이터베이스 저장소 외부에 파일로서 저장되되, 상기 정의된 타입의 일부로서 상기 다른 필드들과의 관련을 상실하지 않는 타입의 데이터를 포함하는 것으로 지정하는 단계

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

상기 객체의 타입은 관리된 코드의 클래스로서 정의되는 방법.
제10항에 있어서,

상기 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청을 수신하는 단계;

상기 객체의 인스턴스의 상기 적어도 하나의 지정된 필드 내의 데이터를 상기 데이터베이스 저장소 외부에 파일로서 저장하는 단계; 및

상기 객체의 인스턴스의 다른 필드들 각각의 데이터를 상기 데이터베이스 저 장소 내에 저장하는 단계

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

상기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터와 상기 데이터베이스 저장소 외부에 파일로서 저장된 필드의 데이터 간의 링크를 제공하는 단계를 더 포함하는 방법.
제12항에 있어서,

상기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터는 상기 데이터베이스의 테이블의 컬럼 내에 프레그먼트로서 저장되고, 상기 컬럼은 상기 사용자 정의 타입으로서 지정되는 방법.
제14항에 있어서,

상기 객체에 관련된 고유 식별자가 상기 객체의 필드들의 데이터와 동일한 로우에 있는 상기 테이블의 또 다른 컬럼 내에 저장되는 방법.
제12항에 있어서,

상기 객체의 상기 적어도 하나의 지정된 필드 내의 데이터는 상기 시스템이 구현된 컴퓨터의 파일 시스템의 소정의 디렉토리 내에 파일로서 저장되는 방법.
사용자 정의 타입의 인스턴스인 객체가 유지될 수 있는 데이터베이스 저장소 - 상기 사용자 정의 타입의 정의는 하나 이상의 필드 및 동작을 포함하고, 상기 필드들 각각은 개별 데이터 타입을 갖고, 상기 정의의 상기 필드들 중 적어도 하나는 상기 타입 정의의 다른 필드들로부터 분리되어 상기 데이터베이스 저장소 외부에 파일로서 저장되는 타입의 데이터를 포함하는 것으로 지정됨 - ; 및

상기 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청을 수신하고, 응답으로, 상기 객체의 인스턴스의 상기 적어도 하나의 지정된 필드 내의 데이터를 상기 데이터베이스 저장소 외부에 파일로서 저장하고, 상기 객체의 인스턴스의 다른 필드들 각각의 데이터를 상기 데이터베이스 저장소 내에 저장하는 데이터베이스 엔진

을 포함하는 시스템.
제17항에 있어서,

상기 데이터베이스 엔진은 상기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터와 상기 데이터베이스 저장소 외부에 파일로서 저장된 필드의 데이터 간의 링크를 제공하는 시스템.
제17항에 있어서,

싱기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터는 상기 데이터베이스의 테이블의 컬럼 내에 프레그먼트로서 저장되고, 상기 컬럼은 상기 사용자 정의 타입으로서 지정되는 시스템.
제19항에 있어서,

상기 객체에 관련된 고유 식별자가 상기 객체의 필드들의 데이터와 동일한 로우에 있는 상기 테이블의 또 다른 컬럼 내에 저장되는 시스템.
제17항에 있어서,

상기 객체의 상기 적어도 하나의 지정된 필드 내의 데이터는 상기 데이터베이스 서버가 실행되고 있는 컴퓨터의 파일 시스템의 소정의 디렉토리 내에 파일로서 저장되는 시스템.
제21항에 있어서,

상기 시스템은, 상기 컴퓨터의 파일 시스템을 통해, 상기 적어도 하나의 필드의 데이터가 상기 데이터베이스 저장소 외부에 저장되는 파일로의 어플리케이션에 의한 액세스를 제공하는 시스템.
제22항에 있어서,

상기 액세스는,

상기 컴퓨터의 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스를 통해 어플리케이션으로부터 상기 파일을 오픈하기 위한 호출을 수신하고 - 상기 호출은 상기 데이터베이스 저장소 내의 상기 객체의 필드 아이덴티티에 의해 상기 객체의 필드를 식별함 - ,

상기 데이터베이스 저장소 내의 상기 객체의 필드의 아이덴티티로부터, 상기 객체의 상기 필드의 데이터를 포함하는 상기 파일로의 상기 컴퓨터의 파일 시스템 내의 경로를 결정하고,

상기 결정된 경로를 이용하여 상기 파일을 오픈하기 위한 호출을 실행함으로써 제공되는 시스템.
제23항에 있어서,

상기 컴퓨터의 파일 시스템은 마이크로소프트 NTFS 파일 시스템을 포함하고, 상기 파일 시스템에 대한 상기 어플리케이션 프로그래밍 인터페이스는 Win32 어플리케이션 프로그래밍 인터페이스를 포함하는 시스템.
사용자 정의 타입의 인스턴스인 객체가 데이터베이스 저장소 내에 유지될 수 있는 시스템에서 사용되기 위해 저장된 프로그램 코드를 갖는 컴퓨터 판독가능 매체로서,

상기 사용자 정의 타입의 정의는 하나 이상의 필드 및 동작을 포함하고, 필드들 각각은 개별 데이터 타입을 갖고, 상기 정의의 상기 필드들 중 적어도 하나는 상기 타입 정의의 다른 필드들로부터 분리되어 상기 데이터베이스 저장소 외부에 파일로서 저장되는 타입의 데이터를 포함하는 것으로서 지정되고,

상기 프로그램 코드는 컴퓨터 시스템 상에서 실행될 때 상기 컴퓨터 시스템이

상기 사용자 정의 타입의 인스턴스인 객체를 저장하라는 요청을 수신하고,

상기 객체의 인스턴스의 상기 적어도 하나의 지정된 필드 내의 데이터를 상기 데이터베이스 저장소 외부에 파일로서 저장하고,

상기 객체의 인스턴스의 다른 필드들 각각의 데이터를 상기 데이터베이스 저장소 내에 저장하게 하는 컴퓨터 판독가능 매체.
제25항에 있어서,

상기 프로그램 코드는, 상기 컴퓨터가 상기 데이터베이스 저장소 내에 저장되는 상기 객체의 필드들의 데이터와 상기 데이터베이스 저장소 외부에 파일로서 저장되는 필드의 데이터 간의 링크를 제공하게 하는 컴퓨터 판독가능 매체.
제25항에 있어서,

상기 프로그램 코드는, 상기 데이터베이스 저장소 내에 저장된 상기 객체의 필드들의 데이터가 상기 데이터베이스의 테이블의 컬럼 내의 프레그먼트로서 저장되게 하며, 상기 컬럼은 상기 사용자 정의 타입으로서 지정되는 컴퓨터 판독가능 매체.
제27항에 있어서,

상기 프로그램 코드는, 상기 컴퓨터가 상기 객체에 관련된 고유 식별자를 상기 객체의 필드들의 데이터와 동일한 로우에 있는 상기 테이블의 또 다른 컬럼 내에 저장하게 하는 컴퓨터 판독가능 매체.
제25항에 있어서,

상기 프로그램 코드는, 상기 컴퓨터가 상기 객체의 상기 적어도 하나의 지정된 필드 내의 데이터를 상기 시스템이 구현된 컴퓨터의 파일 시스템의 소정의 디렉토리 내에 파일로서 저장하게 하는 컴퓨터 판독가능 매체.
제29항에 있어서,

상기 프로그램 코드는, 상기 컴퓨터가 상기 컴퓨터의 파일 시스템을 통해, 상기 적어도 하나의 필드의 데이터가 상기 데이터베이스 저장소 외부에 저장되는 파일로의 어플리케이션에 의한 액세스를 제공하게 하는 컴퓨터 판독가능 매체.
제30항에 있어서,

상기 프로그램 코드는, 상기 컴퓨터가

상기 컴퓨터의 파일 시스템에 대한 어플리케이션 프로그래밍 인터페이스를 통해 상기 어플리케이션으로부터 상기 파일을 오픈하기 위한 호출을 수신하고 - 상기 호출은 상기 데이터베이스 저장소 내의 상기 객체의 필드 아이덴티티에 의해 상 기 객체의 필드를 식별함 - ,

상기 데이터베이스 저장소 내의 객체의 필드의 아이덴티티로부터, 상기 객체의 상기 필드의 데이터를 포함하는 상기 파일로의 상기 컴퓨터의 파일 시스템 내의 경로를 결정하고,

상기 결정된 경로를 이용하여 상기 파일을 오픈하기 위한 호출을 실행함으로써

상기 적어도 하나의 필드의 데이터를 저장하는 파일로의 어플리케이션에 의한 액세스를 제공하게 하는 컴퓨터 판독가능 매체.
제31항에 있어서,

상기 컴퓨터의 파일 시스템은 마이크로소프트 NTFS 파일 시스템을 포함하고, 상기 파일 시스템에 대한 상기 어플리케이션 프로그래밍 인터페이스는 Win32 어플리케이션 프로그래밍 인터페이스를 포함하는 컴퓨터 판독가능 매체.
제25항에 있어서,

상기 객체의 타입은 관리된 코드의 클래스로서 식별되는 컴퓨터 판독가능 매체.