KR101086575B1

KR101086575B1 - 타입 경로 인덱싱

Info

Publication number: KR101086575B1
Application number: KR1020057011824A
Authority: KR
Inventors: 코너 제이. 천닝함; 라마찬드란 벤카테쉬; 에릭 엔. 한슨
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-23
Filing date: 2004-07-29
Publication date: 2011-11-23
Also published as: US7516143B2; JP2007509431A; US7379927B2; US20050091183A1; CN100557605C; JP4653106B2; KR20060123027A; CN1846207A; US20060041574A1; US20060064412A1; WO2005045590A3; US7480646B2; EP1604261A2; EP1604261B1; EP1604261A4; WO2005045590A2

Abstract

객체 타입에 기초한 효과적인 계층적 검색 방법이 제시된다. 추가 정보를 사전 계산하고 이를 고속 룩업 구조에 저장함으로써, 객체 검색 요청을 만족시키는 객체들을 빠르게 식별하는 것이 가능하다. 또한, 이 기술을 사용하여 저장장치 내의 동작들을 위한 객체 하이드레이션을 피하는 것이 가능하다. 또한, 히스토그램과 같은 데이타베이스 통계적 구조를 레버리지하여 각 객체를 검사할 필요 없이 객체들을 평가하는 것이 가능하다.

객체, 계층적 검색, 정보 검색, 정보 저장, 데이타베이스, 히스토그램

Description

타입 경로 인덱싱{TYPE PATH INDEXING}

<관련 출원>

본 출원은 2003년 10월 23일 출원되고, 그 전체가 본 명세서에 참조로 포함되는 미국 출원 제10/692,350호의 우선권을 주장한다.

본 발명은 일반적으로 정보 저장 및 검색 분야에 관한 것이며, 보다 구체적으로는, 객체 타입에 기초한 효과적인 계층적 검색에 관한 것이다.

소비자는 컴퓨터를 주로 통신 및 전통적인 PIM(personal information manager) 스타일 데이타이든 디지탈 음악 또는 사진과 같은 매체이든 개인 정보를 조직화하는데 사용한다. 디지탈 콘텐트의 양과, 원 바이트(raw bite)를 저장하는 능력은 상당히 증가했으나, 이 데이타를 조직화하고 통합하기 위하여 소비자가 이용할 수 있는 방법은 보조를 맞추지 못하고 있다. 지식 근로자들은 상당한 양의 시간을 정보를 관리하고 공유하는데 쓰고 있으며, 어떤 연구에서는 지식 근로자들이 15~25%의 시간을 비생산적인 정보 관련 활동에 소비한다고 추정한다. 다른 연구에서는 전형적인 지식 근로자들은 하루 2.5 시간을 정보 검색에 소비한다고 추정한다.

컴퓨터 시스템에서의 정보 조직화에 대한 종래의 방법들은 파일을 저장하는 데 사용되는 저장 매체의 물리적 조직의 추상화에 기초하여 폴더들로 이루어진 디렉토리 계층으로 다수의 파일을 조직화하는 파일-폴더-및-디렉토리-기반 시스템("파일 시스템")의 사용에 중점을 두고 있다. 1960년대에 개발된 멀틱스(Multics) 운영 체계는 파일, 폴더, 및 디렉토리를 사용하여 운영 체계 레벨에서 데이타의 저장가능한 유닛드을 관리하는 방법을 개척한 것으로 인정받을 수 있다. 특히, 멀틱스는 파일의 물리적 어드레스가 사용자(애플리케이션 및 최종 사용자)에게 투명하지 않은 파일 계층 내에서 심볼화된 어드레스를 사용(그리하여 파일 경로의 개념을 도입)하였다. 이 파일 시스템은 임의의 개별 파일의 파일 형식에 전혀 신경쓰지 않았고, 운영 체계 레벨에서(즉, 계층 내에서 파일의 위치가 아닌) 파일들 간의 관계는 무관한 것으로 취급되었다. 멀틱스의 등장으로, 저장가능한 데이타는 운영 체계 레벨에서 파일, 폴더, 및 디렉토리로 조직화되었다. 이 파일들은 일반적으로 파일 시스템에 의해 관리되는 특수 파일에 포함된 파일 계층 자체("디렉토리")를 포함한다. 이 디렉토리는 다시, 디렉토리 내의 다른 모든 파일들에 대응하는 엔트리 리스트와 계층(이하 폴더라고 함) 내의 이러한 파일들의 노드의 위치를 보유한다. 이는 약 40년간 최신 기술이었다.

그러나, 컴퓨터의 물리적 저장 시스템에 존재하는 정보를 적절하게 표현하면서도, 파일 시스템은 그 물리적 저장 시스템의 추상화가 결코 아니고, 따라서 파일을 이용하기 위해서는 사용자가 다루는 것(콘텍스트, 기능 및 다른 유닛과의 관계)과 운영 체계가 제공하는 것(파일, 폴더, 및 디렉토리) 사이에 간접(해석) 레벨이 필요하다. 결과적으로, 사용자(애플리케이션 및/또는 최종 사용자)는 그렇게 하는 것이 비효과적이고, 일관적이지 않거나, 그렇지 않으면 바람직하지 않은 때에도 파일 시스템 구조로 정보의 유닛들을 강제로 넣을 수 밖에 없다. 기존의 대부분의 파일 시스템은 파일과 폴더를 조직화하기 위한 내포된 폴더 메타포(nested folder metaphor)를 이용하기 때문에, 파일의 수가 증가함에 따라, 유연성있고 효과적인 조직화 스킴을 유지하는데 필요한 노력은 매우 어렵게 된다.

과거에 이러한 파일 시스템의 단점들에 대처하기 위한 몇가지 성공적이지 못했던 시도들이 있었다. 이러한 종래의 시도들 중 일부는 데이타가 물리적 어드레스보다는 콘텐트에 의해 액세스될 수 있는 메카니즘을 제공하기 위한 콘텐트 어드레스가능한 메모리를 사용하는 것을 포함한다. 그러나, 이러한 노력들은 성공적이지 못한 것으로 밝혀졌는데, 이는 콘텐트 어드레스가능한 메모리는 캐시와 메모리 관리 유닛과 같은 장치에 소규모로 이용하는 것에는 유용한 것으로 입증되었지만, 물리적 저장 매체와 같이 대규모로 이용하는 것은 다양한 이유로 아직 불가능하였고, 결국 이러한 해결책은 간단히 존재하지 않는다. 객체 지향 데이타베이스(OODB) 시스템을 사용하는 다른 시도들이 행해졌지만, 이러한 시도들은, 강한 데이타베이스 특성과 우수한 파일이 아닌 표현을 저장하는 특징을 가지지만, 파일 표현을 다루는데 효과적이지 못했고, 속도, 효율, 및 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층 구조의 단순화를 표방하지는 못했다.

"WinFS"(이하 보다 상세히 설명)와 같이 새롭게 개발된 저장 시스템은 데이타베이스에 테이블(들)로서 파일들의 디렉토리를 저장한다. 각 파일은 테이블의 로우로 표현되고, "디렉토리 내의 모든 파일들을 열거"와 같은 파일 시스템 동작은 데이타베이스 엔진에 대한 쿼리를 이용하여 만족된다. 따라서, 저장장치에 대한 기본적인 동작들을 효과적으로 수행하는 것은 데이타베이스 쿼리를 효과적으로 최적화하는 동작이 된다.

이러한 저장 시스템에서, 파일의 개념은 "객체"의 개념으로 확장된다. 파일에 대한 메타데이타는 그 객체에 대한 허용가능한 기술 데이타(descriptive data)를 표현하기 위하여 (저장 시스템에서 정의된) 스키마로 관리 CLR(common language runtime) 객체에 저장된다. 예를 들어, 사진은 그 해상도, 촬영 시간, 위치 정보와 같은 데이타를 저장하는 대표 CLR 객체를 가질 것이다. 이 객체 모델은 데이타 상속을 지원한다. 데이타 상속으로, 다른 것으로부터 타입을 유도하고 새로운 필드를 추가하는 것이 가능하다. 예를 들어, "DriversLicensePicture"와 같은 사진의 서브 클래스가 생성될 수 있다. 이러한 서브 클래스는 Driver's License ID 필드와 같은 추가의 정보를 포함할 것이다.

WinFS와 같은 이들 새로 개발된 저장 시스템에서, 노출된 스키마는 변환층을 통해 테이블로 매핑된다. 사용자는 기본 테이블 상에서 조작하는 대신 데이타의 일련의 측면을 보기만 한다. 이러한 매핑의 정확한 설계가 중요한 것은 아니지만, 이는 WinFS API와 그 아래의 저장 형식 사이의 접착제 역할을 한다. 사용자는 이러한 매핑을 직접 제어하거나 보지 못한다.

WinFS 저장장치는 또한 이전의 종래 파일 시스템에서와 같은 파일 이름과는 반대로, 그 타입에 기초하여 객체들을 쿼리하는 개념을 나타낸다. 타입 기반 쿼리는 정확한 타입 또는 주어진 타입으로부터 유도되는 임의의 타입을 검색할 수 있 다. 이러한 후자의 형태를 계층적 매칭(hierarchical matching)이라고 하며, 이는 통상적인 WinFS 동작이 될 것으로 기대된다.

WinFS의 스키마 모델은 쿼리 프로세서에 대한 몇가지 새로운 문제점을 갖는다. 사용자 정의 타입, 즉 UDT가 널리 이용되고, UDT 타입에 기초한 테이블로부터 모든 UDT를 검색하는 것이 일반적이다. 또한, WinFS는 UDT 상속을 이용하는데, 이는 역시 주어진 타입의 모든 엘리먼트들과 테이블의 임의의 서브타입을 검색하기 위한 요건이다. 각각이 상이한 수의 UDT, 타입, 타입 토폴로지, 및 그 토폴로지 내의 UDT 분포를 포함하는 다수의 테이블이 존재한다. 이러한 속성들은 정확한 카디날리티(cardinality)와 비용 추정을 어렵게 하고, 또한 타입/서브타입 계층에 기초한 값을 효과적으로 검색하는 것을 어렵게 한다.

기존의 데이타 저장장치 및 데이타베이스 기술에 존재하는 이상의 미비점들을 살펴본 결과, 효과적인 타입 계층 검색 및 비용 추정이 요구된다. 본 발명은 이러한 요구들을 충족시키는 것이다.

이하의 개요는 본 발명의 다양한 측면들의 개괄을 제시한다. 이는 본 발명의 모든 주요 측면들을 총망라해서 기술하려는 것도 아니고, 본 발명의 범위를 정의하는 것도 아니다. 오히려, 이 개요는 상세한 설명과 첨부되는 도면들에 대한 도입부의 역할을 하는 것이다.

본 발명은 객체 타입에 기초한 효과적인 계층적 검색을 위한 것이다. 추가의 특수 정보를 사전 계산하고 빠른 룩업(fast-lookup) 구조에 이를 저장함으로써, 객체 검색 요청에 만족하는 객체들을 신속히 식별하는 것이 가능하다. 또한, 이러한 기술을 사용하여 저장장치 내의 특정 동작들을 위해 비용이 드는 객체 하이드레이션(object hydration)을 피하는 것도 가능하다. 더욱이, 각 객체를 조사할 필요 없이 평가 객체들의 수만을 추정하는 새로운 방식으로 데이타베이스의 통계적 구조를 레버리지하는 것이 가능하다.

본 발명의 다른 특징들과 이점들은 이하의 발명의 상세한 설명과 첨부 도면으로부터 명백해 질 것이다.

이상의 개요와, 이하의 바람직한 실시예들의 상세한 설명은 첨부 도면들을 참고할 때 보다 잘 이해될 것이다. 본 발명을 기술하기 위하여, 도면에는 본 발명의 예시적인 구성들이 도시되어 있지만, 본 발명은 개시된 특정 방법들과 수단들에 한정되지 않는다.

도 1은 본 발명의 특징들이 결합될 수 있는 컴퓨터 시스템을 나타내는 블럭도이다.

도 2는 세 개의 콤포넌트 그룹: 하드웨어 콤포넌트, 운영 체계 콤포넌트, 애플리케이션 프로그램 콤포넌트로 나누어진 컴퓨터 시스템을 도시하는 블럭도이다.

도 3은 폴더로 그룹화된 파일들에 대한 트리(tree) 기반 계층 구조를 도시한다.

도 4는 본 발명이 이용될 수 있는 예시적인 저장 플랫폼을 도시한다.

도 5는 타입과 서브 타입에 기초한 객체의 전형적인 계층을 도시한다.

도 6은 본 발명에 따른 주석 달린 타입 계층을 도시한다.

도 7은 종래의 히스토그램을 도시한다.

도 8은 본 발명에 따라 구성될 수 있는 히스토그램을 도시한다.

도 9는 본 발명에 따라 선택도(selectivity) 추정을 생성하는 예시적인 방법의 흐름도이다.

본 발명은 법적 요건을 만족하도록 구체적으로 기술된다. 그러나, 이 기술 자체는 본 특허의 범위를 제한하려는 것이 아니다. 오히려, 발명자들은, 다른 현재의 기술 또는 장래의 기술과 결합하여, 이 문서에 기술된 것과 유사한 다른 단계들 또는 단계들의 조합들을 포함하여, 다른 방식으로도 청구된 발명이 구현될 수 있다고 생각한다. 또한, "단계"라는 용어가 여기서는 이용된 방법들 중 상이한 구성요소들을 내포하는 것으로 이용되었지만, 이 용어는 개별 단계들의 순서가 명백히 기술된 경우를 제외하고는 여기 개시된 다양한 단계들 중에서 임의의 특정 순서를 의미하는 것으로 해석되어서는 안된다.

개요

본 발명은 객체 타입에 기초한 효과적인 계층적 검색에 관한 것이다. 추가의 정보를 사전 계산하고 빠른 룩업 구조에 이를 저장함으로써, 객체 검색 요청에 만족하는 객체들을 신속히 식별하는 것이 가능하다. 또한, 이러한 기술을 사용하여 저장장치에서의 동작들을 위해 비용이 드는 객체 하이드레이션을 피하는 것도 가능하다. 더욱이, 각 객체를 조사할 필요 없이 평가 객체들의 수를 추정하는 새 로운 방식으로 데이타베이스의 통계적 구조를 레버리지하는 것이 가능하다.

본 발명은 특정 타입을 갖는 테이블 내의 값들, 또는 그 타입이 타입 계층에서 주어진 타입에서는 루트인 트리 내에 있는 값들을 신속히 복구하도록 한다. B-트리 인덱스는 특정 위치를 찾고 하나의 값(예컨대, 경로 타입)을 갖는 객체 또는 동일한 값을 갖는 객체 시리즈를 검색하는 능력을 갖는다. 또한, 객체 값의 프리픽스(prefix)를 찾아 모두 동일한 프리픽스를 포함하는 값들의 범위를 반환하는 것도 가능하다. 이러한 속성들은 타입 또는 타입 계층에 기초한 효과적인 검색이 가능하도록 레버리지될 수 있다.

WinFS는 파일 시스템 내에 객체의 개념을 도입하는 파일 시스템/데이타 저장장치이다. 이 저장장치의 동작들 중 하나는 타입에 기초하여 객체를 효과적으로 위치시키고 쿼리할 수 있는 것이다. 본 발명은 어떻게 이러한 동작이 매우 효과적이 될 수 있는지를 기술한다.

본 발명은 UDT에 대한 계층적 타입 id를 제공하는 빌트인 기능을 위한 인터페이스를 제공한다. 계층적 타입 id는 타입 계층 내에서 UDT 표현의 타입을 고유하게 식별하는 가변바이너리(varbinary) 값이다. 이 기능을 쿼리 및 적절한 계산된 컬럼 인덱스를 형성하는데 사용하여, 효과적인 UDT 타입 계층 검색이 지원된다.

예시적인 컴퓨팅 환경

본 명세서와 청구항들에 사용된 이하의 용어들은 다음의 의미를 갖는다.

"객체"는 하드웨어/소프트웨어 인터페이스 시스템 쉘에 의해 최종 사용자에게 노출된 모든 객체들에 걸쳐 공통적으로 지원되는 기본 속성 세트를 갖는 하드웨 어/소프트웨어 인터페이스 시스템에 액세스가능한 저장가능한 정보의 단위이다. 객체는 또한 새로운 속성과 관계가 도입되도록 하는 기능을 포함하여 모든 타입에 걸쳐 공통적으로 지원되는 속성과 관계를 갖는다.

"운영 체계(OS)"는 애플리케이션 프로그램과 컴퓨터 하드웨어 사이에 중간자로서 작용하는 특수 프로그램이다. 운영 체계는 대부분의 경우 쉘(shell)과 커널(kernel)이다.

"하드웨어/소프트웨어 인터페이스 시스템"은 컴퓨터 시스템의 아래의 하드웨어 콤포넌트들과 컴퓨터 시스템 상에서 실행되는 애플리케이션들 간에 인터페이스로서 기능하는, 소프트웨어 또는 하드웨어와 소프트웨어의 조합이다. 하드웨어/소프트웨어 인터페이스 시스템은 전형적으로 운영 체계를 포함한다 (그리고, 일부 실시예에서는, 운영 체계로만 구성된다). 하드웨어/소프트웨어 인터페이스 시스템은 또한 VMM(virtual machine manager), CLR(Common Language Runtime) 또는 그와 기능적으로 동등한 것, JVM(Java Virtual Machine) 또는 그와 기능적으로 동등한 것, 또는 컴퓨터 시스템에서 운영 체계를 대신하거나 그에 추가되는 기타 이러한 소프트웨어 콤포넌트를 포함한다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 애플리케이션 프로그램을 실행하는 환경을 제공하는 것이다. 모든 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 시스템을 사용하기 편리하게 할 뿐만 아니라 효과적인 방식으로 컴퓨터 하드웨어를 이용하도록 하는 것이다.

본 발명의 많은 실시예들은 컴퓨터 상에서 실행된다. 도 1과 이하의 논의는 본 발명의 실시예들이 구현될 수 있는 적절한 컴퓨팅 환경의 개략적이고 일반적인 기술을 제공하려는 것이다. 반드시 요구되는 것은 아니지만, 본 발명은 클라이언트 워크스테이션이나 서버와 같은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능한 명령어들의 일반적인 콘텍스트로 기술될 수 있다. 일반적으로, 프로그램 모듈에는 루틴, 프로그램, 객체, 콤포넌트, 데이타 구조 등 특정 작업을 수행하거나 특정 추상 데이타 타입을 구현하는 것들이 포함된다. 또한, 본 기술분야의 숙련자라면 본 발명이 휴대용 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 혹은 프로그램가능한 소비자 전자장치, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성으로도 실시될 수 있다는 것을 알 것이다. 본 발명은 또한 통신 네트워크를 통해 링크되는 원격 프로세싱 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 컴퓨터 저장 장치 모두에 위치할 수 있다.

도 1에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은 프로세싱 유닛(21), 시스템 메모리(22), 및 시스템 메모리를 포함하는 다양한 시스템 콤포넌트들을 프로세싱 유닛(21)에 결합시키는 시스템 버스(23)를 포함하는, 종래의 개인용 컴퓨터(20) 등을 포함한다. 시스템 버스(23)는 메모리 버스 또는 메모리 콘트롤러, 주변 버스, 및 다양한 버스 아키텍쳐 중 임의의 것을 사용하는 로컬 버스를 포함하는 몇가지 형태의 버스 구조들 중 임의의 것이 될 수 있다. 시스템 메모리는 ROM(24)과 RAM(25)을 포함한다. 시동 동안 등에 개인용 컴퓨터(20) 내의 구성요소들 간에 정보를 전달하는 것을 돕는 기본적인 루틴들을 포함하는 BIOS(basic input/output system)(26)은 ROM(24)에 저장된다.

개인용 컴퓨터(20)는 또한 도시되지 않았지만, 하드 디스크로부터 판독 및 그에 기록하기 위한 하드 디스크 드라이브(27), 제거가능한 자기 디스크(29)로부터 판독 또는 그에 기록하기 위한 자기 디스크 드라이브(28), 및 CD-ROM 또는 기타 광 매체 등 제거가능한 광 디스크(31)로부터 판독 또는 그에 기록하는 광 디스크 드라이브(30)를 더 포함한다. 하드 디스크 드라이브(27), 자기 디스크 드라이브(28), 및 광 디스크 드라이브(30)는 하드 디스크 드라이브 인터페이스(32), 자기 디스크 드라이브 인터페이스(33), 및 광 디스크 드라이브 인터페이스(32)에 의해 각각 시스템 버스(23)에 접속된다. 이 드라이브들과 관련 컴퓨터 판독가능한 매체는 컴퓨터 판독가능한 명령어, 데이타 구조, 프로그램 모듈 및 개인용 컴퓨터(20)를 위한 기타 데이타를 불휘발성 저장한다.

본 명세서에 기술된 예시적인 환경은 하드 디스크, 제거가능한 자기 디스크(29) 및 제거가능한 광 디스크(31)를 이용하였지만, 본 기술분야의 숙련자에게는 자기 카세트, 플래시 메모리 카드, 디지탈 비디오 디스크, 베르누이 카트리지, RAM, ROM 등과 같이, 컴퓨터에 의해 액세스될 수 있는 데이타를 저장할 수 있는 컴퓨터 판독가능한 기타 형태의 매체도 예시적인 동작 환경에서 사용될 수 있다는 것을 알아야 한다.

운영 체계(35), 하나 이상의 애플리케이션 프로그램(36), 기타 프로그램 모듈(37) 및 프로그램 데이타(38)를 포함하는 다수의 프로그램 모듈이 하드 디스크, 자기 디스크(29), 광 디스크(31), ROM(24) 또는 RAM(25)에 저장될 수 있다. 사용자는 키보드(40)와 지시 장치(42)와 같은 입력 장치를 통해 개인용 컴퓨터(20)로 커맨드와 정보를 입력할 수 있다. 기타의 입력 장치들(도시되지 않음)에는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 포함될 수 있다. 이러한 입력 장치들과 기타의 입력 장치들은 시스템 버스에 결합된 시리얼 포트 인터페이스(46)를 통해 프로세싱 유닛(21)에 흔히 접속되나, 패러랠 포트, 게임 포트, USB(Universal Serial Bus)와 같은 기타의 인터페이스에 의해 접속될 수도 있다. 모니터(47)나 기타 형태의 디스플레이 장치도 역시 비디오 어댑터(48)와 같은 인터페이스를 통해 시스템 버스(23)에 접속된다. 모니터(47) 외에, 개인용 컴퓨터는 일반적으로 스피커와 프린터 등 기타의 주변 출력 장치(도시되지 않음)를 포함한다. 도 1의 예시적인 시스템은 또한 호스트 어댑터(55), SCSI(Small Computer System Interface) 버스(56), 및 SCSI 버스(56)에 접속된 외부 저장 장치(62)를 포함한다.

개인용 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터에 대해 논리적 접속을 사용하는 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(49)는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타의 공통 네트워크 노드가 될 수 있으며, 도 1에는 메모리 저장 장치(50)만이 도시되어 있으나, 전형적으로 개인용 컴퓨터(20)에 대해 이상 기술된 구성요소들의 다수 또는 모두를 포함한다. 도 1에 도시된 논리적 접속들은 LAN(local area network)(51) 및 WAN(wide area network)(52)을 포함한다. 이러한 네트워킹 환경은 사무실, 기업용 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔히 찾아볼 수 있다.

LAN 네트워킹 환경에서 사용될 때, 개인용 컴퓨터(20)는 네트워크 인터페이 스나 어댑터(53)를 통해 LAN(51)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 개인용 컴퓨터(20)는 전형적으로 모뎀(54) 또는 인터넷과 같이 WAN(52) 상에서 통신을 확립하기 위한 기타의 수단을 포함한다. 모뎀(54)은 내장형이거나 외장형일 수 있는데, 시리얼 포트 인터페이스(46)를 통해 시스템 버스(23)에 접속될 수 있다. 네트워크 환경에서, 개인용 컴퓨터(20)에 대해 도시된 프로그램 모듈들이나 그의 부분들은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속들은 예시적인 것이며 컴퓨터들 간에 통신 링크를 확립하기 위한 기타의 수단들이 사용될 수 있다는 것을 알아야 할 것이다.

본 발명의 다수의 실시예들은 특히 컴퓨터화된 시스템에 적합한 것으로 생각되지만, 본 명세서의 어떠한 부분도 이러한 실시예들로 본 발명을 한정하려는 것은 아니다. 반대로, 여기서 사용된 용어 "컴퓨터 시스템"은 프레스 버튼을 포함하는, 혹은 버튼 프레스 또는 버튼 프레스와 동등한 것들을 결정할 수 있는 임의의 모든 장치들을 포괄하는 것인데 이러한 장치들이 전자적, 기계적, 논리적, 또는 성질상 가상이든지에 상관없다.

도 2의 블럭도에 도시된 바와 같이, 컴퓨터 시스템(200)은 대략 세 개의 콤포넌트 그룹: 하드웨어 콤포넌트(202), 운영 체계 콤포넌트(204), 및 애플리케이션 프로그램 콤포넌트(206)로 나누어질 수 있다.

도 1을 다시 참조하면, 어떤 컴퓨터 시스템(200)에서는, 하드웨어(202)는 무엇보다도 CPU(21), 메모리(ROM(24) 및 RAM(25) 모두), BIOS(26), 및 키보드(40), 마우스(42), 모니터(47), 및/또는 프린터(도시되지 않음)와 같은 다양한 입력/출력 (I/O) 장치들을 포함할 수 있다. 하드웨어 콤포넌트(202)는 컴퓨터 시스템(200)에 대한 기본 자원을 포함한다.

애플리케이션 프로그램 콤포넌트(206)는 컴파일러, 데이타베이스 시스템, 워드 프로세서, 비지니스 프로그램, 비디오게임 등을 포함하나 이에 한정되지 않는 다양한 소프트웨어 프로그램을 포함한다. 애플리케이션 프로그램은 문제를 해결하고, 해결책을 제공하고, 다양한 사용자들(예컨대, 기계, 다른 컴퓨터 시스템, 및/또는 최종 사용자)를 위해 데이타를 처리하는데 컴퓨터 자원이 이용되는 수단을 제공한다.

운영 체계 콤포넌트(204)는 운영 체계 자체 및 그의 쉘 및 커널을 포함한다. 운영 체계(OS)는 애플리케이션 프로그램들과 컴퓨터 하드웨어 사이에 중간자로서 역할을 하는 특수 프로그램이며, 운영 체계의 목적은 사용자가 애플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 모든 운영 체계의 목적은 컴퓨터 시스템을 사용하기 편리하도록 할 뿐만 아니라, 효과적인 방식으로 컴퓨터 하드웨어를 이용하도록 하는 것이다.

운영 체계는 일반적으로 시동시에 컴퓨터 시스템에 로딩된 뒤 컴퓨터 시스템 내의 모든 애플리케이션 프로그램들(단순히 "애플리케이션들")을 관리한다. 애플리케이션 프로그램들은 애플리케이션 프로그램 인터페이스(API)를 통해 서비스를 요청함으로써 운영 체계와 상호작용한다. 일부 애플리케이션 프로그램들은 최종 사용자가 커맨드 언어 또는 GUI(graphical user interface)와 같은 사용자 인터페이스를 통해 운영 체계와 상호작용하도록한다.

운영 체계는 전통적으로 애플리케이션을 위한 다양한 서비스를 수행한다. 다수의 프로그램이 동시에 구동되는 멀티태스킹 운영 체계에 있어서, 운영 체계는 어느 애플리케이션이 어떠한 순서로 구동되어야 하는지 그리고 다른 애플리케이션으로 교환되기 전에 얼만큼의 시간이 허용되어야 하는지를 결정한다. 운영 체계는 또한 다수의 애플리케이션 사이에서 내부 메모리를 공유하는 것을 관리하고, 하드 디스크, 프린터 및 다이얼 업 포트와 같은 부착된 하드웨어 장치들로 그리고 그로부터의 입출력을 다룬다. 운영 체계는 또한 동작 상태 및 발생한 오류에 대한 메세지를 각 애플리케이션 (및, 어떤 경우, 최종 사용자)에 보낸다. 운영 체계는 또한 배치 작업(예컨대, 프린팅)의 관리의 부담을 덜어 초기 애플리케이션이 이 작업으로부터 벗어나서 다른 프로세싱 및/또는 동작을 재개개할 수 있도록 할 수 있다. 병렬 프로세싱을 제공할 수 있는 컴퓨터에서, 운영 체계는 또한 동시에 하나 이상의 프로세서에서 구동하도록 프로그램을 나누는 것을 관리한다.

운영 체계의 쉘은 운영 체계에 대한 상호작용적인 최종 사용자 인터페이스 ("커맨드 해석기"라고도 알려짐)이다. 쉘은 애플리케이션 프로그램 및 최종 사용자에게도 직접적으로 액세스가능한 운영 체계의 외층이다. 쉘과는 반대로, 커널은 하드웨어 콤포넌트와 직접적으로 상호작용하는 운영 체계의 최내층이다.

관련 분야의 숙련자라면 잘 알고 있겠지만, "파일"은 운영 체계에 의해 별개의(저장가능하고 검색가능한) 엔티티로서 다루어질 수 있는 정보의 엔티티(운영 체계 자체 뿐만 아니라, 프로그램, 데이타 세트 등을 포함하나 이에 한정되지 않음)이다. 현대의 운영 체계(윈도우즈, 유닉스, 리눅스, 맥 OS 등)에서, 파일은 운영 체계에 의해 다루어지는 저장가능한 정보(데이타, 프로그램 등)의 기본 단위이며, 파일들의 그룹은 "폴더"로 조직화된다. 마이크로소프트 윈도우즈, 매킨토시, 및 기타의 운영 체계에서, 폴더는 검색, 이동, 하나의 엔티티로서 달리 다루어질 수 있는 파일들의 집합이다. DOS, z/OS와 대부분의 유닉스 기반 운영 체계와 같은 일부 다른 운영 체계에서는, 폴더보다는 "디렉토리"라는 용어가 사용되며, 초기의 애플 컴퓨터 시스템(예컨대, Apple IIe)은 "카탈로그"라는 용어를 사용하였다. 그러나, 여기서 이러한 모든 용어들은 동의어이며 상호교환가능하며, 여기서는 계층적 정보 저장 구조에 대한, 그리고 그에 대해 참조하는 모든 동등한 용어들을 또한 포함한다.

본 기술분야의 숙련자에게 잘 알려지고 이해되는 바와 같이, 디렉토리(즉, 폴더들의 디렉토리)는 트리 구조의 노드를 포함하는 폴더 내의 위치에 기초하여 파일들이 그룹화되는 트리 기반 계층 구조이다. 예를 들어, 도 3에서 도시된 바와 같이, DOS 기반 파일 시스템의 기본 폴더(즉 "루트 디렉토리")(302)는 복수의 폴더(304)를 포함하며, 각 폴더는 추가의 폴더들(이 특정 폴더의 "서브폴더들")을 또한 포함하며, 이들 각각은 역시 추가의 폴더들(308)을 무한이 포함한다. 이들 폴더들 각각은 하나 이상의 파일들(310)을 갖지만, 운영 체계 레벨에서, 폴더 내의 개별 파일들은 트리 계층에서의 위치를 제외하고는 공통적인 것이 없다. 이렇게 파일들을 폴더 계층으로 조직화하는 방식은 이러한 파일들을 저장하는데 사용되는 전형적인 저장 매체(예컨대, 하드 디스크, 플로피 디스크, CD-ROM 등)의 물리적인 조직화를 간접적으로 반영한다는 것은 놀랄 일이 아니다.

이상에 부가하여, 각 폴더는 서브폴더들과 그의 파일들에 대한 컨테이너이다 - 즉, 폴더는 이러한 서브폴더들과 파일들을 보유한다. 예를 들어, 폴더가 운영 체계에 의해 삭제될 때, 그 서브폴더들과 파일들도 역시 삭제된다(각 서브폴더의 경우, 그 자신의 서브폴더들과 파일들을 하위 경로로 포함한다). 유사하게, 각 파일은 하나의 폴더만이 보유하고, 파일이 복제될 수 있고 복제된 파일이 상이한 폴더에 위치할지라도 복제된 파일 자체는 원본과 직접적인 연결이 없는 구별되고 분리된 엔티티이다(예컨대, 원본 파일에 대한 변경은 운영 체계 레벨에서는 복제 파일에 반영되지 않는다). 이러한 관점에서, 폴더는 물리적인 컨테이너와 개념적으로 동등한 것이며, 파일은 컨테이너 내부의 별개의 분리된 물리적 엘리먼트와 개념적으로 동등한 것이기 때문에, 결국 파일과 폴더는 특성상 "물리적"이다.

본 발명과 함께 사용될 수 있는 데이타를 조직화, 검색, 및 공유하기 위한 저장 플랫폼은 객체라고 하는 데이타 형태를 포함하는 모든 형태의 데이타를 위한 저장장치로 설계된다. 도 4를 참조하면, 본 발명에 따른 저장 플랫폼(400)은 데이타베이스 엔진(414) 상에서 구현되는 데이타 저장장치(402)를 포함한다. 일실시예에서, 이 데이타베이스 엔진은 객체 관계형(object relational) 확장을 갖는 관계형 데이타베이스 엔진을 포함한다. 일실시예에서, 관계형 데이타베이스 엔진(414)은 마이크로소프트 SQL 서버 관계형데이타베이스 엔진을 포함한다.

데이타 저장장치(402)는 데이타의 조직화, 검색, 공유, 동기화, 및 보안을 지원하는 데이타 모델(404)을 구현한다. 특정 형태의 데이타가 스키마(440)와 같은 스키마에서 기술되며, 저장 플랫폼(400)은 이하에 보다 완벽히 기술되는 바와 같이, 이들 스키마를 배치하고 이들 스키마를 확장하기 위한 도구(446)를 제공한다.

데이타 저장장치(402) 내에서 구현된 변경 추적 메카니즘(406)은 데이타 저장장치에 대한 변경을 추적하는 능력을 제공한다. 데이타 저장장치(402)는 또한 보안 기능(408)과 프로모션/디모션(promotion/demotion) 기능(410)을 제공한다. 데이타 저장장치(402)는 또한 데이타 저장장치(402)의 기능들을 이 저장 플랫폼을 이용하는 다른 저장 플랫폼 콤포넌트들과 애플리케이션 프로그램들(예컨대, 애플리케이션 프로그램들(450a, 450b, 450c)에 제공하기 위한 애플리케이션 프로그래밍 인터페이스(412) 세트를 제공한다.

본 발명의 저장 플랫폼은 또한 API(422)를 더 포함하는데, 이는 애플리케이션 프로그램들(450a, 450b, 450c)과 같은 애플리케이션 프로그램들이 저장 플랫폼의 이상의 모든 기능들에 액세스하고 이 스키마들에 기술된 데이타에 액세스하도록 한다. 저장 플랫폼 API(422)는 OLE DB API(424) 및 마이크로소프트 윈도우즈 Win32 API(426)과 같은 다른 API들과 함께 애플리케이션 프로그램에 의해 사용될 수 있다.

본 발명의 저장 플랫폼(400)은 사용자나 시스템 사이에서 데이타의 공유를 용이하게 하는 동기화 서비스(430)를 포함하는 다양한 서비스들(438)을 애플리케이션 프로그램들에 제공할 수 있다. 예를 들어, 동기화 서비스(430)는 데이타 저장장치(402)와 동일한 형식을 갖는 다른 데이타 저장장치들(440)과의 상호동작성 및 다른 형식을 갖는 데이타 저장장치들(442)에 대한 액세스를 가능하게 할 수 있다. 저장 프랫폼(400)은 또한 윈도우즈 NTFS 파일 시스템(418)과 같은 기존의 파일 시스템과 데이타 저장장치(402)와의 상호동작성을 허용하는 파일 시스템 기능들을 제공한다.

적어도 일부 실시예들에서, 저장 플랫폼(430)은 또한 데이타에 작용되고 다른 시스템과 상호작용하도록 하는 추가의 기능들을 갖는 애플리케이션 프로그램들을 제공할 수 있다. 이러한 기능들은 Info Agent 서비스(434) 및 통지 서비스(432)와 같은 부가 서비스들(428) 형태 뿐만 아니라 기타 유틸리티(436)의 형태로 구현될 수 있다.

적어도 일부 실시예들에서, 저장 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템 내에 구현되거나, 그의 불가분의 부분의 형태를 취한다. 이에 한정되는 것은 아니지만, 예를 들어, 본 발명의 저장 플랫폼은 운영 체계, VMM(virtual machine manager), CLR(Common Language Runtime) 또는 그와 기능적으로 동등한 것, 또는 JVM(Java Virtual Machine) 또는 그와 기능적으로 동등한 것으로 구현되거나, 그의 불가분의 부분의 형태를 취한다.

통상적인 저장 파운데이션과 스키마화된 데이타를 통해, 본 발명의 저장 플랫폼은 소비자, 지식 근로자, 기업을 위한 보다 효과적인 애플리케이션 개발을 가능하게 한다. 이는 그 데이타 모델에 고유한 기능들을 가능하게 할 뿐만 아니라, 기존의 파일 시스템과 데이타베이스 액세스 방법들을 포함하고 확장하는 풍부하고 확장가능한 프로그래밍 표면 영역을 제공한다.

본 설명과 다양한 도면들에서, 본 발명의 저장 플랫폼(400)은 "WinFS"라고 한다. 그러나, 저장 플랫폼에 이 명칭을 사용하는 것은 단지 설명을 편리하게 하기 위한 것이며 어떠한 방식으로든 한정을 하려는 것은 아니다.

본 발명의 저장 플랫폼(400)의 데이타 저장장치(402)는 저장장치 내에 존재하는 데이타의 조직화, 검색, 공유, 동기화, 보안을 지원하는 데이타 모델을 구현한다. 본 발명의 데이타 모델에서, "객체"는 저장 정보의 기본적인 단위이다. 이 데이타 모델은, 이하에 보다 완벽히 기술되는 바와 같이, 객체들과 객체 확장들을 선언하고 객체들간의 관계를 확립하고 객체들을 조직화 및 카테고리화하는 메카니즘을 제공한다.

이 데이타 모델은 타입들 간의 서브타입-서브타입 관계를 정의하도록 한다. 서브타입-서브타입 관계는 Type A가 Type B에 대한 BaseType이면 B의 모든 인스턴스(instance)는 또한 A의 인스턴스가 되는 경우이어야 하는 방식으로 정의된다. 이를 표현하는 다른 방식은 B에 맞는 모든 인스턴스는 또한 A에도 맞아야 한다는 것이다. 예를 들어, A가 Type String이라는 속성 Name을 갖고 B가 Type Int16이라는 속성 Age를 갖는다면, B의 임의의 인스턴스는 Name과 Age를 모두 가져야 한다. 타입 계층은 루트에 하나의 서브타입을 갖는 트리라고 생각될 수 있다. 자체가 어떠한 서브타입도 갖지 않는 리프 서브타입에, 루트로부터 나오는 브랜치들은 제1 레벨의 서브타입들을 제공하고, 이 레벨의 브랜치들은 제2 레벨의 서브타입들을 제공하는 등이다. 트리는 균일한 깊이로 제한되지 않으나 어떤 사이클을 포함할 수는 없다. 주어진 Type은 제로 또는 많은 서브타입을 가질 수 있고 제로 또는 하나의 서브타입을 가질 수 있다. 주어진 인스턴스는 그 타입의 수퍼타입들과 함께 기 껏해야 하나의 타입에 맞을 수 있다. 이를 다른 방식으로 설명하면, 트리의 임의의 레벨에서 주어진 인스턴스에 대해서, 이 인스턴스는 그 레벨에서 기껏해야 하나의 서브타입에 맞을 수 있다는 것이다.

일실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는, 관계형 데이타베이스 엔진(414)은 빌트인 스칼라 타입(built-in scalar type)을 지원한다. 빌트인 스칼라 타입은 "고유"하고 "단순"하다. 이 타입은 사용자가 그 자신의 타입을 정의할 수 없다는 점에서 고유하고 복잡한 구조를 내포할 수 없다는 점에서 단순하다. 사용자 정의 타입("UDTs")은 복잡하고 구조화된 타입들을 정의함으로써 사용자들이 타입 시스템을 확장하도록 하여 고유의 스칼라 타입 시스템 이상의 타입 확장성을 위한 메카니즘을 제공한다. 일단 사용자에 의해 정의되면, UDT는 빌트인 스칼라 타입이 사용될 수 있는 타입 시스템 어디에서도 사용될 수 있다.

이 저장 플랫폼 스키마는 데이타베이스 엔진 저장장치 내의 UDT 클래스에 매칭된다. 데이타 저장 객체는 Base.Item 타입으로부터 유도되는 UDT 클래스에 매핑된다. 확장은 또한 UDT 클래스에 매핑되고 상속을 이용한다. 루트 Extension 타입은 Base.Extension이고, 이로부터 모든 Extension 타입들이 유도된다.

UDT는 CLR 클래스이다 - 이는 상태(즉, 데이타 필드)와 행동(즉, 루틴)을 갖는다. UDT는 임의의 관리 언어 - C#, VB.NET 등을 이용하여 정의된다. UDT 방법과 연산자는 그 타입의 인스턴스에 대해 T-SQL로 불러들여질 수 있다. UDT는, 예를 들어, 로우 내의 컬럼의 타입, T-SQL로 된 루틴 파라미터의 타입, 또는 T-SQL로 된 변수의 타입이 될 수 있다.

이하의 예는 UDT의 기본을 설명한다. MapLib.dll이 MapLib이라고 하는 어셈블리를 갖는다고 가정한다. 이 어셈블리에는, 네임스페이스 BaseType 아래에 Point라고 하는 클래스가 있다.

이하의 T-SQL 코드는 클래스 Point를 Point라고 하는 SQL Server UDT에 결합시킨다. 첫번째 단계는 MapLib 어셈블리를 데이타베이스로 로딩하는 "CreateAssembly"를 불러들이는 것이다. 두번째 단계는 "Create Type"을 불러 UDT "Point"를 생성하고 이를 관리 타입 BaseTypes.Point에 결합시키는 것이다.

"Point" UDT는 일단 생성되면, 테이블 내의 컬럼으로 사용될 수 있고 아래에 도시된 바와 같이 방법들이 T-SQL로 불러들여질 수 있다.

UDT 클래스에 대해 저장 플랫폼 스키마를 매핑하는 것은 높은 레벨에서는 아주 간단하다. 일반적으로, 저장 플랫폼 Schema는 CLR 네임스페이스로 매핑된다. 저장 플랫폼 Type은 CLR 클래스로 매핑된다. CLR 클래스 상속은 저장 플랫폼 Type의 상속을 반영하고, 저장 플랫폼 Property는 CLR 클래스 속성에 매핑된다.

예시적인 실시예

전형적인 데이타 저장장치는 각각이 UDT와 같은 타입을 갖는 기본 객체들의 테이블을 포함한다. 행동(방법이라고도 함)이 타입에 추가될 수 있다. 신규한 데이타 저장장치 중 일부는 상속을 제공하는데, 여기서 타입은 새로운 타입을 생성하도록 추가의 방법으로 확장될 수 있다. 예를 들어, 타입은 ".doc" 또는 ".jpeg"과 같은 확장자가 될 수 있다. 이러한 타입들에 대한 상속 확장자는 예컨대 ".doc2" 또는 ".jpeg2"가 될 수 있다. 본 발명은 타입니스(typeness)에 대한 쿼리(즉, ".doc"에 대한 쿼리 뿐만 아니라 ".doc"에 대한 확장)를 허용한다.

도 5에 타입들의 예시적인 상속 계층이 도시되어 있다. 도 5에서, 타입은 "document"(500)이다. "legal document"(510) 및 "review document"(530)가 "document"(500)에 대한 서브타입으로 도시되어 있다. "legal document"(510)의 서브타입은 "Washington legal document"(520)이다. 타입(예컨대, "document") 및 /또는 서브타입(예컨대, "document" 및/또는 "legal document" 및/또는 "Washington legal document")에 대해 쿼리가 행해질 수 있다.

종래의 검색 기술은 컬럼들을 갖는 테이블을 사용하는데, 여기서 컬럼들 중 하나는 대응하는 객체 컬럼의 각 객체들에 대한 타입 컬럼이었다. 검색을 실행하기 위해, 검색 엔진이 각 로우를 통과하고, 모든 객체를 메모리에 로딩함으로써 인스턴스화하고, 그 타입을 확인하여 맞는 것이 있는지 결정한다. 이러한 기술은 매우 느리고, 검색을 효율적으로 하기 위한 최적의 실행 계획을 결정할 방법이 없다.

보다 새로운 검색 기술들은 컬럼을 계산했는데, 여기서는 다른 관련 컬럼들의 값들에 기초하여 사전 계산된 값들을 갖는 테이블에 추가의 컬럼이 제공된다. 이 기술은 검색을 가속화하지만, 추가의 계산된 컬럼을 저장하기 위한 추가의 메모리가 필요하다. "타입 경로" 컬럼이라고 하는 특수 계산된 컬럼이 그 타입 또는 UDT의 함수로 제공될 수 있다. 이는 임의의 타입 또는 서브타입을 검색하는데 사용될 수 있다.

본 발명의 일측면은 타입니스에 기초하여 일련의 객체 인스턴스들을 효과적으로 검색하는 능력이다. 값이 사전 계산되고 바람직하게는 객체 인스턴스들을 그들의 타입에 기초하여 구별하기 위한 충분한 정보를 저장한다. 이 값은 특정 타입 또는 타입 계층의 모든 타입들(모두 공통의 조상을 공유)에 대한 효과적인 검색을 지원하기 위한 충분한 정보를 포함한다. 추가적으로, 이 값은 B-트리 또는 기타의 인덱싱 구조와 같은 빠른 액세스 구조에서 사용되어 타입 또는 타입 계층에 기초하여 객체들을 검색할 수 있다.

시스템 내의 각 타입에 대해서 값이 할당되는 것이 바람직하다. 이 값은 적어도 타입 계층의 각 "레벨"(루트로부터 동일 깊이)에서 고유해야 한다. 각 타입에 대해서, 각 부모 클래스에 대한 타입 값은 모든 이전 프리픽스 동작의 결과로 또는 어떠한 프리픽스 동작도 수행되지 않았으면 원래 타입으로 프리픽스된다. 동일 레벨에서의 모든 엘리먼트들은 동일한 저장 형식(길이)으로 저장되어야 한다.

타입의 인스턴스를 나타낼 때, 이상 설명한 바와 같이 값이 결정되고, 그 값이 그 객체와 함께 저장된다. 이를 데이타베이스에 저장할 때, 객체와 사전 계산된 값은 동일 테이블의 별도의 컬럼 혹은 다른 저장 구조로, 테이블 1에 도시된 바와 같이 저장될 수 있다. 테이블 1은 예시적인 ID들과 그들의 해당 문서 타입을 보여주는 샘플 데이타 타입 테이블이다.

ID	Document Type
1	Document Instance
1.2	LegalDocument Instance
1.3	ReviewDocument Instance
1.2.4	WA_LegalDocument Instance

테이블 1

따라서, 각 타입에는 도 6의 주석 달린 계층에서 도시된 바와 같이, 숫자나 다른 식별자가 주어진다. 도 6에 도시된 바와 같이, "document" 타입에는 식별자 ID=1이, "legal document"에는 식별자 ID=2가, "review document"에는 식별자 ID=3이, "Washington legal document"에는 식별자 ID=4가 주어진다. 객체의 인스턴스가 생성될 때마다, 적절한 식별자가 타입에 첨부된다. 따라서, 테이블 1에 도시된 바와 같이, 예를 들어, "document"는 타입 경로 "1"로 인코딩되고 "legal document"는 "1.2"로 인코딩되고 "Washington legal document"는 "1.2.4"로 인코딩 될 것이다.

이하의 테이블 2는 객체 이름, UDT, 타입 경로를 저장하는 다른 예시적인 저장 테이블을 도시한다. 객체의 인스턴스가 생성될 때마다, 적절한 식별자가 타입에 첨부된다. 따라서, 테이블 2에 도시된 바와 같이, 예를 들어, "document"는 타입 경로 "1"로 인코딩되고 "legal document"는 "1.2"로 인코딩되고 "Washington legal document"는 "1.2.4"로 인코딩될 것이다.

컬럼 1 - 객체 이름	UDT	타입 경로
Doc1	Document	1
Doc2	Legal Document	1.2
Doc3	Review Document	1.3
Doc4	Washington Legal Document	1.2.4

테이블 2

b-트리 인덱스와 같이 빠른 액세스 구조가 사전 계산된 값들을 포함하는 컬럼에 대해서 생성될 수 있다. 이 인덱싱 구조는 바람직하게는 주어진 값 또는 값의 주어진 프리픽스를 포함하는 아이템들을 효과적으로 찾는 능력을 갖는다. 특정 값이 공통이라고 발견하면, 프리픽스 동작은 보통 SQL로 LIKE 'PREFIX%' 구문과 같은 스트링 값을 발견하는데만 사용된다. LIKE 구문은 인덱싱 구조에서 프리픽스를 검색하기 위한 동작을 이용하여 효과적으로 계산될 수 있다.

이러한 동작은 인코딩된 계층의 타입과 서브타입들을 검색하는데 사용될 수 있다. 예를 들어, 명령어 "LIKE '1.2%'"는 "1.2"(%는 와일드카드라고 가정)로 시작하는 인코딩을 갖는 임의의 객체를 찾을 것이다. 따라서, 본 실시예에서, 이러한 예시적인 명령어는 "legal document" 타입 또는 "Washington legal document" 타입인 모든 객체들을 검색하고 반환할 것이다.

특정 타입 또는 타입 계층을 검색하는데 필요한 동작들은 특정 타입의 모든 객체들 또는 특정 타입으로부터 유도되는 모든 객체들을 식별하기 위해 인덱스 상에서 동작할 수 있다. 이 인덱싱 구조에 대한 동일성 매치가 전자에 대해서 이용되고, 프리픽스 매치가 후자를 만족시킨다. 이러한 인코딩은 타입 또는 타입 계층의 위치에 기초한 객체에 대한 고속 룩업을 가능하게 한다. 데이타베이스 시스템 내의 B-트리는 전형적으로 이러한 동작들을 둘 다 지원한다(LIKE 'aaa%' 쿼리를 만족시키는데 사용되는 프리픽스 기능을 가짐).

본 발명의 특징들에 따르면, 데이타 테이블의 로우가 효과적으로 검색될 수 있다. 타입 경로 컬럼 상의 인덱스가 b-트리의 형태로 생성될 수 있다. 예를 들어, 타입 경로 "1.2"를 나타내는 모든 로두들은 리프 노드에 저장될 것이다. 리프 노드들은 로우들을 갖는 테이블에 대응한다. b-트리 구조가, 예컨대, "seek" 커맨드에 응답하여 내려가면서 비교가 행해진다. "seek" 동작은 특정 값 뿐만 아니라 특정 프리픽스에 대해서 검색을 하는데 사용될 수 있다고 생각된다.

데이타베이스 구조 대신 인메모리(in-memory) 구조가 사용될 수 있다고 생각된다. 역 인덱스가 생성되고 서픽스(suffix) 동작이 사용될 수 있다. 또한, 가변 길이의 인코딩이 각 계층 레벨에 대해 사용될 수 있다. 또한, 동일 속성들을 갖는 일부 비수치적 표현이 사용될 수 있다.

타입 치환성을 사용하여, 모든 타입의 객체들이 저장될 수 있고, "IS OF (Type)" 연산자를 사용하여 객체 타입과 서브타입에 의해 검색이 필터링될 수 있다. 본 발명의 특징들에 따르면, "IS OF"와 같은 동작 조건자(predictate)가 타입 경로 컬럼에 매핑될 수 있다. "IS OF ONLY"와 같은 다른 동작 조건자들이 사용될 수 있다. 따라서, 비용이 드는 객체 하이드레이션이나 인스턴스화를 피할 수 있다.

타입 계층에 기초하여 값을 사전 계산하는 것이 그 타입을 결정하기 위하여 객체를 하이드레이팅하는 것을 회피하는데 사용될 수 있다. 객체 하이드레이션/인스턴스화는 비용이 들고 타입에 의한 쿼링이 일반적이라고 가정하면, 타입 제약을 평가하지 않는 객체들에 대한 객체 인스턴스화를 피하는 것이 바람직하다. 타입이 객체 인스턴스화를 회피하면서 완전한 신뢰성을 갖는 필터링을 여전히 가능하게 하는 방식으로 인코딩될 수 있다면, 이는 성능을 향상시킬 수 있다.

또한, 사용자 타입-확인 요청을 중단하고 이를 내부적으로 재기록하여 사전 계산된 값에 대한 동등한 동작을 대신 수행하는 것이 가능하다. 이는 사전 계산된 값이 존재하는 모든 객체에 대해서 행해질 수 있다.

데이타베이스 시스템에서 구현되는 타입에 기초한 신속한 객체 구별 실시예에 있어서, 객체가 주어진 타입 또는 그 타입으로부터 유도되는 임의의 타입인 테이블 내의 로우들의 수를 결정하는 것이 바람직하다. 이러한 추정 문제를 해결하기 위한 종래의 기술들은 추측하고, 모든 값들이 동일하게 가능성이 있다고(즉, 균등 분포) 가정하고, 테이블 카디날리티를 사용하여 추정을 하거나, 히스토그램을 사용하여 보다 빈번한 값들과 덜 빈번한 값들의 범위를 추적하는 것을 포함한다. 전형적으로, 주어진 타입에 대해서 얼마나 많은 값들이 존재하는지를 결정하는데 히스토그램이 유용하다. 본 발명의 특징들은 전체 히스토그램에 대한 선택도를 추 정한다.

히스토그램은 쿼리가 얼마나 긴지를 추정하도록 만들어질 수 있다. 히스토그램은 각 타입의 객체들의 수를 보여준다. 예시적인 히스토그램이 도 7에 도시되어 있다. 여기서, "document", "legal document", "review document", 및 "Washington document" 타입의 객체들의 예시적인 수가 히스토그램 형식으로 도시되어 있다. 그러나, 이 히스토그램은 타입의 계층을 제공하지는 않는다. 타입 계층은 어렵고 비용이 드는 룩업 기술에 의해 결정될 수 있다.

본 발명의 특징들은 룩업 기술이 필요 없이 타입 계층이 구분될 수 있도록 , 히스토그램에 대해 인코딩하는 기술에 관한 것이다. 이 인코딩 기술에 따르면, 각 타입에는 도 6의 주석 달린 타입 계층에 도시된 바와 같이, 숫자 또는 다른 식별자가 주어진다. 따라서, 계층이 이러한 가변 길이의 인코딩 스킴을 이용하여 식별될 수 있는 히스토그램이 생성될 수 있다. 예를 들어, 도 8에 도시된 바와 같이, 각 타입/서브타입의 숫자에 따라 1.2.4는 1.2의 서브타입이며 1.2는 1이 서브타입이라는 것을 쉽게 식별할 수 있다.

도 9는 본 발명에 따른 선택도 추정을 생성하는 예시적인 방법의 흐름도를 도시한다. 한 세트의 객체들에 대해 타입 계층 쿼리의 선택도를 추정하기 위해, 단계 900에서 본 명세서에 기술된 인코딩 방법을 사용하고, 단계 910에서 컬럼으로 이 인코딩 결과를 저장하고, 단계 920에서 그 컬럼에 대해 (그 컬럼에 대해 별도로 혹은 그 컬럼에 대한 인덱스 생성 결과로) 히스토그램을 생성하는 것이 바람직하다.

그 다음, 단계 930에서, 타입 또는 그 타입의 임의의 서브타입으로부터 어느 객체가 검색되는지를 기술하면서, 쿼리 타입이 인코딩된다. 히스토그램의 각 엘리먼트에 대해, 단계 940에서 인코딩된 쿼리 타입이 히스토그램 엔트리의 프리픽스인지를 결정한다. 그렇다면, 단계 950에서, 이 히스토그램 단계와 관련된 엘리먼트들의 수가 히스토그램의 다른 "매칭 엘리먼트들"의 수에 추가된다. 프리픽스가 아니면, 단계 960에서, 이 히스토그램 단계와 관련된 엘리먼트들의 수가 히스토그램의 "매칭하지 않는 엘리먼트들"에 추가된다.

모든 히스토그램 단계들이 진행되면, 이 계층적 타입-매칭 쿼리의 선택도 추정이 단계 990에서, "매칭 엘리먼트들"의 수를 가져와 이를 "매칭 엘리먼트들"의 수와 "매칭하지 않는 엘리먼트들"의 수의 합으로 나눔으로써 결정된다.

따라서, 이 바이너리 인코딩에 대한 히스토그램을 사용하여 타입 계층에서 UDT의 분포에 관한 통계적 정보를 결정하는 것이 가능하다. 이 계층적 인코딩 지식으로 선택도 추정을 하는 동안 히스토그램을 거침으로써, 매우 정확한 카디날리티 추정이 쿼리에서 사용되도록 생성될 수 있다. 기술된 알고리즘 당 선택도를 추정하는데 고유 함수가 사용되면, IS OF에 대한 CLR 호출을 완전히 제거하고 이 고유 함수에 대한 카디날리티 추정만을 할 수 있어야 한다.

본 발명에 따르면, UDT로부터 타입-id를 반환하는 함수가 구현된다. 다른 함수는 타입-id로부터 계층적 타입-id 인코딩을 반환한다. WinFS와 같은 저장 시스템은 바람직하게는 모든 UDT-호스팅 테이블(예컨대, 객체 테이블) 상에 계산된 컬럼을 생성한다. 일실시예에서, IS OF 스칼라는 추가/대체 조건자를 포함한다고 생각된다. 예를 들어, UDT를 포함하는 기본 테이블을 찾는데 UDT 값이 사용될 수 있다. 그러면 컬럼들을 계산한 기본 테이블은 스칼라 표현을 포함하는 계산된 컬럼의 존재를 결정하는데 사용된다. 이러한 컬럼이 발견되면, 내재된 조건자가 추가된다.

각 UDT 타입이 작은(예컨대, 4-바이트) 고정 길이 값이라고 가정한다. 또한, 계층적 타입-id는 부모 타입-id를 스트링이나 바이너리 필드로 연결하는 것으로 정의될 수 있다. UDT를 포함하는 각 로우가 이러한 계층적 인코딩을 나타내는 계산된 컬럼을 가진다면, 이러한 새로운 컬럼에 대해 인덱스가 생성될 수 있다. 주어진 타입 계층의 모든 UDT를 반환하는 동작은 레인지 프리픽스 동작을 이용하여 구현될 수 있으며, 타입-id에 대한 정확한 매치를 사용하여 비계층 매치들을 해결할 수 있다.

예시적인 계층적 타입 id가 아래의 함수로 제공된다:

함수	파라미터	결과
HIERARCHICAL_TYPE_ID	(UDT_expression)	타입 계층의 루트로부터 UDT_expression의 가장 특정 타입까지의 경로를 따라 타입들의 타입 id들의 연결을 포함하는 가변캐릭터(varchar) 값. 이 가변캐릭터 값은 인쇄되지 않는 문자들을 포함할 수 있다.

UDT_expression은 임의의 사용자 정의 타입 값을 갖는 표현이 될 수 있다. HIERARCHICAL_TYPE_ID 함수는 바람직하게는 결정적이고 정확하다. 이는 계층적 타입 id를 사용하여 유도된 계산된 컬럼들에 대한 인덱스를 구축하는 능력을 제공한다. 계산된 컬럼들은 지속적으로 만들어질 필요는 없는 것으로 생각된다.

타입 경로가 다른 것의 프리픽스인지를 결정하기 위해, 시스템은 내부적으로 기존의 LIKE 프리픽스-스캐닝 기능을 사용하여 만들어진 HAS_PREFIX 연산자를 사용한다. 이 프리픽스 스캐닝 기능은 prefix_string이 %와 같은 임의의 와일드카드 문자들을 포함하지 않는 어떠한 고정 스트링인 "character_expression LIKE 'prefix_string%'"의 형태의 조건들에 대한 매칭을 구현하는데 사용된다. 이 HAS_PREFIX 연산자는 바람직하게는 사용자에게 가시적이지 않다. HAS_PREFIX는 인덱스가 이용가능하면 인덱스 스캔을 사용할 수 있다.

계층적 타입 id 값은 인덱스에 저장되어야 하는 데이타의 양을 줄이도록 짧은 것이 바람직하다. 계층적 타입 id는 WinFS 스키마의 타입들에 대해 100 문자보다 작은 길이인 것이 바람직하다.

내부적 타입 id가 주어진 계층적 타입 id를 검색하는 함수는 인덱스 생성 동안 사용되기 때문에 빠른 것이 바람직하다.

바람직하게는, 타입은 그의 인스턴스들이 데이타베이스에 남아있는 동안(즉, 타입 또는 그의 조상들 중 어느 것이 여전히 존재하는 테이블의 정의에 사용되면) 취소되거나 삭제될 수 없다. 그렇지 않고, 취소된 타입의 계층적 타입 id를 포함하는 인덱스 엔트리는 인덱스 내에 남아있지만, 이들을 해석하는 것이 가능하지 않을 것이다. 또한, 하나을 취소한 뒤 새로운 타입을 추가하면 오류를 유발하는 기존의 인스턴스의 것과 같은 계층적 타입 id를 만들 것이다.

계층적 타입 id의 내부 형식은 길이가 4 바이트의 배수이고, 타입 계층의 루트로부터 UDT_expression의 가장 특정 타입까지의 경로를 따르는 타입들의 (예컨대, 내부적으로 4 바이트 정수로 저장된) 타입 id들의 연결을 포함하는, 가변바이 너리 값이 되는 것이 바람직하다.

그 값이 사용자 정의 타입인 속성을 갖는 큰 테이블의 경우, 그 속성의 값들이 특정 타입을 갖거나, 주어진 타입의 서브타입인 로우들을 빠르게 검색하는 것을 지원하는 것이 바람직할 수 있다. 이러한 상황에서 신속한 검색을 지원하기 위해, HIERARCHICAL_TYPE_ID를 사용하여 생성된 계산된 컬럼 상에 인덱스가 생성될 수 있다.

이하의 UDT의 타입 계층을 가정한다:

또한, 아래와 같이 테이블이 정의된다:

IS OF 연산자를 사용하여 pcol 타입을 필터링하면서 person 로우들을 빠르게 룩업할 수 있도록 하기 위하여, person 테이블의 person.pcol에 대한 계층적 타입 id에 대해 계산된 컬럼과 인덱스가 아래와 같이 추가된다:

예를 들어서, 이는 사용자가 "person" 테이블이 큰 경우에도 시간제 근로자들에 대한 모든 정보를 빠르게 찾도록 한다.

HIERARCHICAL_TYPE_ID의 CLUSTERED 인덱스는 주어진 타입의 모든 값들을 빠르게 검색하는 것이 높은 우선순위인 경우에 생성될 수 있다. 인덱스 CLUSTERED를 만드는 것은 동일한 타입의, 또는 타입 계층의 동일한 서브트리, 동일 페이지 또는 디스크 상의 인접 페이지들 상의 그룹 값들일 것이다.

쿼리 재기록에 대해서, IS OF 조건자가 HIERARCHICAL_TYPE_ID를 통해 내부적으로 구현되고, HIERARCHICAL_TYPE_ID로부터 유도된 계산된 컬럼의 인덱스가 IS OF 연산자를 사용하는 타입 상에서 쿼리들을 가속하는 것을 도울 수 있는 일반적인 문장을 포함하는 것으로 생각된다.

시스템은 내부적으로 쿼리 재기록을 사용하여 타입 조건자으로 알려진 IS [NOT] OF 조건자를 처리한다. 타입 조건자의 바람직한 형태는 다음과 같다:

형태

의 표현은,

와 동등하다.

형태

의 타입 조건자는 UDT-expression의 타입이 type_list의 엔트리에 맞는지를 테스트하는 조건자들을 분리하는 것으로 재기록된다.

UDT-expression IS OF an Inclusive_UDT_specification인지를 결정하는 테스 트는 다음과 같이 재기록된 쿼리로 표현된다:

여기서, <<constant hierarchical type id of UDT_name>>은 UDT_name의 계층적 타입을 나타내는 가변바이너리 상수이다.

UDT-expression IS OF an Exclusive_UDT_specification인지를 보는 테스트는 다음과 같이 재기록된 쿼리로 표현된다:

이상의 재기록 조건에서 HIERARCHICAL_TYPE_ID(UDT-expression) 표현은 person_htid_idx와 같은 동일한 표현으로부터 만들어진 계산된 컬럼 상의 인덱스와 매치할 것이다.

이하의 예들은 IS OF와 IS OF (ONLY...) 조건자를 지원하도록 이상 기술된 재기록 규칙들의 응용을 도시한다.

-- 임의의 종류의 근로자인 모든 사람들을 발견.

-- 재기록된 쿼리:

-- employee_t 타입이나 그의 서브타입은 아닌 모든 사람을 발견.

-- 재기록된 쿼리:

-- 임금을 받거나 시간제 근로자인 모든 사람들을 발견

-- 재기록된 쿼리:

함수 TYPE_ID()의 오버로드된 버전이 UDT 표현의 빌트인 타입 id를 반환하도록 추가된다고 생각된다.

또한 TYPE_NAME() 함수의 오버로드된 버전이 단일 가변바이너리 계층적 타입 id(htid) 아규먼트에 대해 추가되어 그 htid를 갖는 타입에 대한 스트링 이름을 반환할 수 있다고 생각된다. 이하의 예는 테이블 내의 계층에서 구별되는 각 타입의 발생을 어떻게 카운트하는지를 보여준다.

-- 각 타입의 사람들의 수를 카운트

압축 스킴이 계층적 타입 id에 제공될 수 있다. 이는 계층적 타입 id로부터 만들어진 인덱스 키 크기의 크기를 줄일 것이다. 예를 들어, 이들을 기본-254 정수(0-254 데시말의 바이트 값의 수치를 가짐)로 인코딩하고 분리자로서 바이트 255를 사용한다. 그러면 계층적 타입 id는 이하의 형태가 될 것이다:

많은 경우, 이는 그 경로에서 타입 id 당 4가 아닌 2 또는 3 바이트만이 될 것이다.

타입 포함 기능은 타입 조건자의 type_list가 하나 이상의 엔트리를 가질 때 쿼리 재기록에 추가될 수 있다. 예를 들어,

는,

와 동등한데, employee_t가 person_t의 서브타입이기 때문이다.

결론

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

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

본 발명이 다양한 도면들의 바람직한 실시예들로 기술되었지만, 다른 유사한 실시예들이 이용되거나 본 발명의 동일한 기능을 그로부터 벗어나지 않고 수행하기 위한 바람직한 실시예에 대해 수정 및 추가가 행해질 수 있다는 것이 이해된다. 예를 들어, 본 발명의 예시적인 실시예들이 개인용 컴퓨터의 기능을 모사하는 디지탈 장치의 관점에서 기술되었지만, 본 기술분야의 숙련자라면 본 발명이 이러한 디지탈 장치들에 한정되지 않고, 본 출원에 기술된 바와 같이 게임 콘솔, 핸드핼드 컴퓨터, 휴대용 컴퓨터 등, 유선이든 무선이든 임의의 수의 기존의 또는 신규한 컴퓨팅 장치들 또는 환경들에 적용될 수 있으며, 통신 네트워크를 통해 접속되고 네트워크를 거쳐 상호작용하는 임의의 수의 이러한 컴퓨팅 장치들에 적용될 수 있다는 것을 인식할 것이다. 또한, 특히 무선 네트워크 장치의 수가 증가함에 따라, 핸드핼드 장치의 운영 체계를 포함하는 다양한 컴퓨터 플랫폼과 기타 애플리케이션 특정 운영체계들이 고안된다는 점이 강조되어야 한다. 따라서, 본 발명은 임의의 하나의 실시예에 한정되는 것이 아니라, 첨부된 청구항들에 따른 범위과 영역 내에서 해석되어야 한다.

Claims

쿼리를 처리하기 위한 컴퓨터 시스템으로서,

프로세서;

메모리;

문서의 테이블 및 관련된 사전 계산된 값들을 포함하는 데이타 저장소 - 상기 사전 계산된 값들은 계층적 검색에 따른 타입에 기초하여 객체들을 분별하는 정보를 포함하고, 각 문서는 문서 타입의 계층 내의 관련된 문서 타입을 갖고, 문서와 관련된 상기 문서 타입은 사전 계산된 값들을 계산하는 데 사용되며, 상기 사전 계산된 값은 루트 문서 타입에서부터 상기 문서와 관련된 상기 문서 타입까지의 경로를 따라 상기 문서 타입들의 타입 값들을 연결함으로써 생성되고, 상기 사전 계산된 값은 예약된 분리자 바이트에 의해 연결된 타입 값들을 분리함으로써 압축됨 - ; 및

각 문서에 대해, 상기 각 문서와 관련된 상기 사전 계산된 값이 상기 쿼리를 만족하는지를 판정하기 위해 상기 데이타 저장소 내의 상기 테이블에 액세스하고, 상기 쿼리를 만족하는 상기 사전 계산된 값을 포함하는 쿼리 결과들을 생성하는 문서 검색 시스템 - 상기 문서 검색 시스템은 상기 사전 계산된 값들에 대한 히스토그램을 적어도 부분적으로 작성함으로써 상기 쿼리의 선택도(selectivity)의 추정치를 생성하고, 상기 히스토그램은 상기 문서 타입들의 계층 내의 문서 타입들을 나타내는 복수의 엘리먼트를 갖고, 각 엘리먼트는 상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 문서들의 양(quantity)에 관련됨 - ;

을 포함하고,

인코딩된 쿼리 타입에 기초하여 검색하기 위해 하나 이상의 문서를 설명하도록 상기 쿼리를 인코딩하고,

상기 히스토그램의 각 엘리먼트에 대해, 상기 인코딩된 쿼리 타입이, 상기 히스토그램의 상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 프리픽스(prefix)인지를 판정하고,

상기 인코딩된 쿼리 타입이 상기 히스토그램의 상기 각 엘리먼트에 의해 나타난 상기 문서 타입의 프리픽스라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 관련된 양을 매칭 엘리먼트들의 합(sum)에 추가하고,

상기 인코딩된 쿼리 타입이 상기 문서 타입의 프리픽스가 아니라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 상기 관련된 양을 비 매칭 엘리먼트들의 합에 추가하고,

상기 매칭 엘리먼트들 및 비 매칭 엘리먼트들의 합의 함수로서 상기 쿼리의 선택도의 상기 추정치를 생성하는

컴퓨터 시스템.
컴퓨터 실행가능 명령어들을 저장하는 컴퓨터 판독가능 저장 매체로서, 상기 컴퓨터 실행가능 명령어들은, 실행될 때에, 컴퓨터 시스템으로 하여금,

문서의 테이블 및 관련된 사전 계산된 값들을 포함하는 데이타 저장소에 액세스하고 - 상기 관련된 사전 계산된 값들은 계층적 검색에 따른 타입에 기초하여 객체들을 분별하는 데 사용되는 정보를 포함하고, 상기 문서들의 테이블 내 각 문서는 문서 타입의 계층 내의 관련된 문서 타입을 갖고, 상기 관련된 문서 타입은 상기 각 문서와 관련된 사전 계산된 값을 계산하는 데 사용되며, 상기 사전 계산된 값은 루트 문서 타입에서부터 상기 문서와 관련된 상기 문서 타입까지의 경로를 따라 상기 문서 타입들의 타입 값들을 연결함으로써 생성되고, 상기 사전 계산된 값은 예약된 분리자 바이트에 의해 상기 연결된 타입 값들을 분리함으로써 압축됨 -,

각 문서에 대해, 상기 각 문서와 관련된 상기 사전 계산된 값이 쿼리를 만족하는지를 판정하여, 상기 쿼리를 만족하는 상기 사전 계산된 값을 포함하는 쿼리 결과들을 생성하고,

상기 사전 계산된 값들에 대한 히스토그램을 적어도 부분적으로 작성함으로써 상기 쿼리의 선택도의 추정치를 생성하고 - 상기 히스토그램은 상기 문서 타입들의 계층 내의 문서 타입들을 나타내는 복수의 엘리먼트를 가짐 -,

상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 문서들의 양과 관련된 각 엘리먼트에 대해, 인코딩된 쿼리 타입에 기초하여 검색하기 위해 하나 이상의 문서를 설명하도록 상기 쿼리를 인코딩하고,

상기 히스토그램의 각 엘리먼트에 대해, 상기 인코딩된 쿼리 타입이, 상기 히스토그램의 상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 프리픽스인지 여부를 판정하고,

상기 인코딩된 쿼리 타입이 상기 히스토그램의 상기 각 엘리먼트에 의해 나타난 상기 문서 타입의 프리픽스라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 관련된 양을 매칭 엘리먼트들의 합에 추가하고,

상기 인코딩된 쿼리 타입이 상기 문서 타입의 프리픽스가 아니라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 상기 관련된 양을 비 매칭 엘리먼트들의 합에 추가하고,

상기 매칭 엘리먼트들 및 비 매칭 엘리먼트들의 합의 함수로서 상기 쿼리의 선택도의 상기 추정치를 생성함으로써,

쿼리를 처리하게 하는 컴퓨터 판독가능 저장 매체.
쿼리를 처리하는 컴퓨터 구현 방법으로서,

문서의 테이블 및 관련된 사전 계산된 값들을 포함하는 데이타 저장소에 액세스하는 단계 - 상기 관련된 사전 계산된 값들은 계층적 검색에 따른 타입에 기초하여 객체들을 분별하는 데 사용되는 정보를 포함하고, 상기 문서들의 테이블 내 각 문서는 문서 타입들의 계층 내의 관련된 문서 타입을 갖고, 상기 관련된 문서 타입은 상기 각 문서와 관련된 사전 계산된 값을 계산하는 데 사용되며, 상기 사전 계산된 값은 루트 문서 타입에서부터 상기 문서와 관련된 상기 문서 타입까지의 경로를 따라 상기 문서 타입들의 타입 값들을 연결함으로써 생성되고, 상기 사전 계산된 값은 예약된 분리자 바이트에 의해 상기 연결된 타입 값들을 분리함으로써 압축됨 - ;

각 문서에 대해, 상기 각 문서와 관련된 상기 사전 계산된 값이 상기 쿼리를 만족하는지를 판정하여, 상기 쿼리를 만족하는 상기 사전 계산된 값을 포함하는 쿼리 결과들을 생성하는 단계;

상기 사전 계산된 값들에 대한 히스토그램을 적어도 부분적으로 작성함으로써 상기 쿼리의 선택도의 추정치를 생성하는 단계 - 상기 히스토그램은 상기 문서 타입들의 계층 내의 문서 타입들을 나타내는 복수의 엘리먼트를 가짐 - ;

상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 문서들의 양과 관련된 각 엘리먼트에 대해, 인코딩된 쿼리 타입에 기초하여 검색하기 위해 하나 이상의 문서를 설명하도록 상기 쿼리를 인코딩하는 단계;

상기 히스토그램의 각 엘리먼트에 대해, 상기 인코딩된 쿼리 타입이, 상기 히스토그램의 상기 각 엘리먼트에 의해 나타나는 상기 문서 타입의 프리픽스인지 여부를 판정하는 단계;

상기 인코딩된 쿼리 타입이 상기 히스토그램의 상기 각 엘리먼트에 의해 나타난 상기 문서 타입의 프리픽스라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 관련된 양을 매칭 엘리먼트들의 합에 추가하는 단계;

상기 인코딩된 쿼리 타입이 상기 문서 타입의 프리픽스가 아니라고 판정된 상기 히스토그램의 각 엘리먼트에 대해, 상기 관련된 양을 비 매칭 엘리먼트들의 합에 추가하는 단계; 및

상기 매칭 엘리먼트들 및 비 매칭 엘리먼트들의 합의 함수로서 상기 쿼리의 선택도의 상기 추정치를 생성하는 단계

를 포함하는 컴퓨터 구현 방법.
제1항에 있어서,

각 문서 타입은 사용자 정의 타입(UDT: user-defined type)인 컴퓨터 시스템.
제1항에 있어서,

문서 타입은 다른 문서 타입의 서브타입인 컴퓨터 시스템.
제1항에 있어서,

각 문서는 관련된 타입 경로는 갖는 컴퓨터 시스템.
제6항에 있어서,

각 타입 경로는 상기 테이블 내 계산된 컬럼에 속하는 컴퓨터 시스템.
제6항에 있어서,

각 타입 경로는 가변 길이 인코딩 값을 포함하는 컴퓨터 시스템.
제8항에 있어서,

각 가변 길이 인코딩된 값은 상기 관련된 문서의 상기 문서 타입의 계층적 레벨에 대응하는 컴퓨터 시스템.
제2항에 있어서,

각 문서 타입은 사용자 정의 타입(UDT)인 컴퓨터 판독가능 저장 매체.
제2항에 있어서,

문서 타입은 다른 문서 타입의 서브타입인 컴퓨터 판독가능 저장 매체.
제2항에 있어서,

상기 데이타 저장소는 각 타입 경로를 저장하기 위한 계산된 컬럼을 포함하는 컴퓨터 판독가능 저장 매체.
제2항에 있어서,

각 타입 경로는 가변 길이 인코딩 값을 포함하는 컴퓨터 판독가능 저장 매체.
제13항에 있어서,

각 가변 길이 인코딩 값은 상기 관련된 문서의 상기 문서 타입의 계층적 레벨에 대응하는 컴퓨터 판독가능 저장 매체.
컴퓨터에 의해 실행될 때에, 상기 컴퓨터로 하여금, 프로세스를 수행하게 하는, 명령어들이 저장된 컴퓨터 판독가능 저장 매체로서,

상기 프로세스는,

데이타베이스에 문서들 및 식별자들을 저장하는 것 - 상기 식별자들 중 각 식별자는 문서를 식별함 -;

상기 문서와 관련된 문서 타입을 나타내는 문서 타입 값을 저장하는 것 - 상기 문서 타입은 부모 클래스를 가지며, 복수의 레벨로 조직된 문서 타입들의 계층의 일부이고, 특정 문서 타입에 대한 상기 문서 타입 값은 상기 계층의 주어진 레벨 내 상기 문서 타입들 중에서 고유(unique)함 -;

루트 문서 타입에서부터 상기 문서 타입들의 계층 내 상기 문서 타입까지의 경로를 보여주는 상기 문서 타입에 대한 타입 경로를 나타내는 값을 저장하는 것 - 상기 값은, 상기 문서와 관련된 상기 문서 타입을 나타내는 상기 문서 타입 값을 상기 문서 타입의 부모 클래스의 타입 경로를 나타내는 값에 첨부함으로써 생성됨 -;

예약된 분리자 바이트에 의해 상기 문서 타입의 상기 부모 클래스의 상기 타입 경로를 나타내는 상기 값과 상기 문서 타입 값을 분리함으로써 상기 타입 경로를 나타내는 상기 값을 압축하는 것 - 상기 타입 경로를 나타내는 상기 값은, 상기 루트 문서 타입과 동일한 길이를 갖는 문서 타입들 중에서 균일한 길이를 갖는 가변 길이 인코딩된 값을 포함하고, 상기 가변 길이 인코딩 값은 문서 타입들의 상기 계층 내의 상기 문서 타입의 계층 레벨에 대응하고, 상기 문서 타입은 사용자 정의 타입(UDT)임 -; 및

상기 압축된 값을 사용하여, 상기 문서 타입들의 계층 내의 상기 UDT의 타입을 식별하는 것

을 포함하는, 컴퓨터 판독가능 저장 매체.
제15항에 있어서,

상기 문서 타입은 다른 문서 타입의 서브타입인 컴퓨터 판독가능 저장 매체.
사용자 정의 타입(UDT) 식별을 위한 컴퓨터 구현 방법으로서,

컴퓨터를 이용하여, 데이타베이스에 문서들 및 식별자들을 저장하는 단계 - 상기 식별자들 중 각 식별자는 문서를 식별함 - ;

상기 문서와 관련된 문서 타입을 나타내는 문서 타입 값을 저장하는 단계 - 상기 문서 타입은 부모 클래스를 가지며, 복수의 레벨로 조직된 문서 타입들의 계층의 일부이고, 특정 문서 타입에 대한 상기 문서 타입 값은 상기 계층의 주어진 레벨 내 상기 문서 타입들 중에서 고유함 - ;

루트 문서 타입에서부터 상기 문서 타입들의 계층 내 상기 문서 타입까지의 경로를 보여주는 상기 문서 타입에 대한 타입 경로를 나타내는 값을 저장하는 단계 - 상기 값은, 상기 문서와 관련된 상기 문서 타입을 나타내는 상기 문서 타입 값을 상기 문서 타입의 부모 클래스의 타입 경로를 나타내는 값에 첨부함으로써 생성됨 - ;

예약된 분리자 바이트에 의해 상기 문서 타입의 상기 부모 클래스의 상기 타입 경로를 나타내는 상기 값과 상기 문서 타입 값을 분리함으로써 상기 타입 경로를 나타내는 상기 값을 압축하는 단계 - 상기 타입 경로를 나타내는 상기 값은, 상기 루트 문서 타입과 동일한 길이를 갖는 문서 타입들 중에서 균일한 길이를 갖는 가변 길이 인코딩된 값을 포함하고, 상기 가변 길이 인코딩된 값은 문서 타입들의 상기 계층 내의 상기 문서 타입의 계층 레벨에 대응하고, 상기 문서 타입은 사용자 정의 타입(UDT)임 - ; 및

압축된 상기 값을 사용하여, 상기 문서 타입들의 계층 내의 상기 UDT의 타입을 식별하는 단계

를 포함하는 컴퓨터 구현 방법.
제17항에 있어서, 상기 문서 타입은 다른 문서 타입의 서브타입인 컴퓨터 구현 방법.
복수의 객체들에 대한 계층 쿼리의 선택도 추정치를 생성하는 방법으로서,

상기 복수의 객체들에 대해 상기 계층 퀴리를 수신하는 단계 - 상기 복수의 객체 중 각 객체는 관련된 타입을 갖고, 각 타입은 식별자를 갖고, 상기 각 타입은 상속 확장(inheritance extension)을 이용하여 확장가능하고, 상기 각 타입은 사용자 정의 타입(UDT)임 - ;

식별자로부터 유도된 타입 경로를 갖는 상기 복수의 객체들 중 상기 각 개체를 인코딩하는 단계 - 상기 타입 경로는 가변 길이 인코딩된 값을 포함하고, 상기 가변 길이 인코딩된 값은 관련된 객체의 타입의 계층 레벨에 대응함 - ;

상기 인코딩의 결과들을 컬럼에 저장하는 단계;

인코딩된 객체들을 이용함으로써 상기 컬럼의 히스토그램을 생성하는 단계;

상기 각 개체에 대해, 상기 히스토그램을 이용함으로써 상기 각 개체의 타입 경로가 상기 쿼리를 만족하는지를 판정하는 단계;

매칭 객체들의 수를 매칭 객체들의 수와 비 매칭 객체들의 수의 합으로 나눔으로써 상기 객체들의 상기 계층 쿼리의 선택도 추정치를 생성하는 단계 - 상기 매칭 객체들은 상기 쿼리를 만족하는 상기 타입 경로를 가짐 - ;

상기 계층 쿼리의 상기 선택도 추정치를 저장 장치에 출력하는 단계

를 포함하는 선택도 추정치 생성 방법.
제19항에 있어서,

어느 타입 경로들이 상기 쿼리를 만족할지를 판정하는 단계를 더 포함하는 선택도 추정치 생성 방법.
제19항에 있어서,

상기 쿼리가, 만족될 수 있는 타입을 갖도록 상기 쿼리를 인코딩하는 단계를 더 포함하는 선택도 추정치 생성 방법.
제19항에 있어서,

각 타입이, 다른 타입의 서브타입이 될 수 있는 선택도 추정치 생성 방법.
제19항에 있어서,

각 객체가, 타입들의 계층 내 관련된 타입을 갖는 선택도 추정치 생성 방법.
삭제