KR20070001781A - 데이터에 대한 함수 적용의 결과에 대한 구조화된 인덱스 - Google Patents

Abstract

인덱싱된 뷰 또는 실체화된 뷰가 복수의 값으로 된 속성을 가지는 베이스 테이블 상의 제2 인덱스로서 이용된다. 이것은 인덱스를 이용하여 네스팅된 데이터에서 검색하는 것을 제공한다. 더구나, 언네스트 오퍼레이션의 결과에 대해 인덱싱이 제공된다. 언네스팅 오퍼레이션의 결과에 대해 뷰를 인덱싱하는 것은 네스팅된 집합의 컨텐츠를 인덱싱하는 능력을 제공한다. 하나의 그러한 언네스팅 오퍼레이션은 "크로스 어플라이 언네스트"이다. 이것은 질의 실행 플랜에 대한 추가 옵션을 제공하고, 더 최적화된 질의를 유도한다. 후방 결합은 인덱싱된 뷰로부터 베이스 테이블에 제공되어 인덱싱된 뷰에 존재하지 않는 베이스 테이블로부터의 필드들이 액세스 경로로서 인덱싱된 뷰를 이용하여 처리되는 테이블 상의 질의 결과에 포함될 수 있도록 허용한다. 이것은 인덱싱된 뷰에는 없지만 베이스 테이블에는 존재하는 질의 결과에 칼럼을 포함시키는 수단을 제공한다. 후방 결합은 논리적 로우 로케이터로서 기능하는 고유 클러스터링 키를 통해 하나의 테이블 인덱싱된 뷰로부터 베이스 테이블로 지원된다. 그러므로, 시스템은 고유 클러스터링 키를 통해 인덱싱된 뷰로부터 베이스 테이블로 후방 결합할 수 있다. 이들 특징들은 인덱싱된 뷰의 이용이 복수-세트 또는 복수-값으로 된 속성의 컨텐트에 대해 테이블을 인덱싱하도록 허용한다.

정보 저장, 데이터 검색, DBMS, 인덱싱, 데이터 관리

Description

데이터에 대한 함수 적용의 결과에 대한 구조화된 인덱스{STRUCTURED INDEXES ON RESULTS OF FUNCTION APPLICATIONS OVER DATA}

본 출원은 2004년 3월 8일자로 출원된 미국 출원 번호 제10/795,623호의 우선권을 주장하며, 그 개시물은 전체가 참조로서 본 명세서에 포함되어 있다.

본 발명은 일반적으로는 정보 저장 및 검색 분야에 관한 것으로, 특히 저장된 데이터의 효율적인 검색에 관한 것이다.

소비자들은 전통적인 개인 정보 매니저(PIM) 스타일 데이터 또는 디지털 음악 또는 사진과 같은 매체인지와 관계없이, 주로 그들의 컴퓨터를 통신 및 개인 정보 조직에 이용한다. 디지털 컨텐트의 양, 및 미처리된 바이트를 저장하는 능력은 엄청나게 증가되었다. 그러나, 소비자들이 이러한 데이터를 조직하고 단일화하기 위해 이용가능한 방법들은 이를 따라가지 못했다. 지식 노동자들은 엄청난 양의 시간을 정보를 관리하고 공유하는데 소비하고, 일부 연구들은 지식 노동자들이 그 시간의 15-25%를 비-생산적인 정보 관련 활동에 소비한다고 추정하고 있다. 다른 연구들은 전형적인 지식 노동자들이 정보를 검색하는데 약 1일당 2.5시간을 소비한다고 추정하고 있다.

컴퓨터 시스템에서 정보 조직의 전통적인 접근법은 파일을 저장하는데 이용 되는 저장 매체의 물리적 조직의 추상화에 기초하여 파일을 폴더의 디렉토리 계층으로 조직하는 파일-폴더-및-디렉토리 기반 시스템("파일 시스템")의 이용에 집중되었다. 1960년대에 개발된 멀틱스(Multics) 오퍼레이팅 시스템은 오퍼레이팅 시스템 레벨에서 데이터의 저장가능한 유닛을 관리하는 파일, 폴더, 및 디렉토리의 이용을 개척한 것으로 믿어지고 있다. 특히, 멀틱스는 파일의 계층내에서 심볼 어드레스를 이용했고(그럼으로써, 파일 경로의 사상을 도입함), 여기에서 파일의 물리적 어드레스가 사용자(어플리케이션 및 최종 사용자)에게 명백하지 않았다. 이러한 파일 시스템은 임의의 개별적인 파일의 파일 포맷에 대해 전혀 관심이 없었고, 파일들간의 관계는 오퍼레이팅 시스템 레벨에서(즉, 계층내의 파일의 위치 이외에서) 무관한 것으로 여겨졌다. 멀틱스의 출현 이래로, 저장가능한 데이터는 오퍼레이팅 시스템 레벨에서 파일, 폴더, 및 디렉토리로 조직되었다. 이들 파일들은 일반적으로 파일 시스템에 의해 유지된 특별한 파일에 실시되는 파일 계층 자체("디렉토리")를 포함한다. 이러한 디렉토리는 이에 대해, 디렉토리의 모든 다른 파일에 대응하는 엔트리 리스트 및 계층에서 그러한 파일의 노드 위치(여기에서, 폴더로 지칭됨)을 유지한다. 그러한 것이 약 40년 동안 본 기술분야의 수준이었다.

그러나, 컴퓨터의 물리적 저장 시스템에 상주하는 정보의 합리적인 표현을 제공하면서도, 파일 시스템은 그럼에도 불구하고, 그 물리적 저장 시스템의 추상화이며, 따라서, 파일의 활용은 사용자가 조작하는 것(컨텍스트, 특징, 및 다른 유닛과의 관계를 가지는 단위)과 오퍼레이팅 시스템이 제공하는 것(파일, 폴더 및 디렉토리)간의 어느 정도의 간접적인 조치(해석)를 요구한다. 결과적으로, 사용자(어 플리케이션 및/또는 최종 사용자)는 그렇게 하는 것이 비효율적이고, 일관되지 못하며 또는 다르게는 바람직하지 못한 경우에도 정보 단위를 파일 시스템 구조로 강제할 수 밖에 없다. 대부분의 존재하는 파일 시스템은 파일 및 폴더를 구성하기 위해 네스팅된 폴더 메타포어를 활용하기 때문에, 파일의 개수가 증가함에 따라, 유연하고 효율적인 구성 스킴을 유지하는데 필요한 노력이 매우 위압적이 된다.

파일 시스템의 단점을 대처하는 수개의 성공하지 못한 시도들이 과거에 있었다. 이들 이전 시도들의 일부는 데이터가 물리적 어드레스보다는 컨텐트에 의해 액세스될 수 있는 메커니즘을 제공하기 위해 컨텐트 어드레싱 가능한 메모리의 이용과 관련된다. 그러나, 컨텐트 어드레싱가능한 메모리는 캐시 및 메모리 관리 유닛과 같은 디바이스에 의해 소규모 이용에 유용한 것으로 증명된 반면, 물리적 저장 매체와 같은 디바이스에 대한 대규모 이용은 여러 가지 이유 때문에 아직 가능하지 않았기 때문에, 이들 노력들은 성공적이지 못한 것으로 증명되었고, 따라서 그러한 해결책은 존재하지 않는다. 오브젝트-지향 데이터베이스(OODB) 시스템을 이용한 다른 시도들이 수행되었지만, 강력한 데이터베이스 특성 및 양호한 비-파일 표현을 특징으로 하는 이들 시도들은 파일 표현을 핸들링하는데 효율적이지 않았고 하드웨어/소프트웨어 인터페이스 시스템 레벨에서 파일 및 폴더 기반 계층 구조의 속도, 효율성 및 단순성을 복제할 수 없었다.

"WinFS"(이하에 더 설명됨)와 같은 새롭게 개발된 저장 시스템은 파일의 디렉토리를 데이터베이스에 테이블(들)로서 저장한다. 각 파일은 베이스 테이블에서 로우(row)로 표현되고, "디렉토리에서 모든 파일을 열거하라"와 같은 파일 시스템 오퍼레이션은 데이터베이스 엔진에 대한 질의를 이용하여 만족된다. 그러므로, 스토어에 대해 기본적인 오퍼레이션을 효율적으로 수행하는 것은 데이터베이스 질의를 효율적으로 최적화하는 오퍼레이션이 된다.

그러한 저장 시스템에서, 파일의 개념은 "오브젝트"의 개념으로 확장된다. 파일에 관한 메타 데이터는 그 오브젝트에 대한 허용가능한 기술적(descriptive) 데이터를 나타내는 스키마(저장 시스템에 저장됨)를 가지는 관리된 CLR(공통 언어 런타임) 오브젝트에 저장된다. 예를 들어, 화면(picture)은 그 해상도, 소요된 시간, 및 위치 정보와 같은 데이터를 저장할 대표적 CLR 오브젝트를 가질 것이다. 이러한 오브젝트 모델은 데이터 계승(inheritance)을 지원한다. 데이터 계승으로, 다른 것으로부터의 타입을 도출하여 새로운 필드를 추가할 수 있다. 예를 들면, "DriversLicensePicture"와 같은 화면의 서브-클래스가 생성될 수 있다. 그러한 서브-클래스는 운전자의 면허증 ID 필드와 같은 추가의 정보를 포함할 것이다.

WinFS와 같은 이들 새롭게 개발된 저장 시스템에서, 노출된 스키마는 번역 계층을 통해 테이블들에 매핑된다. 사용자들은 베이스 테이블에서 동작하는 대신에 데이터의 뷰 시리즈만을 본다. 이러한 매핑의 정확한 디자인은 중요하지 않지만, WinFS API와 기저 저장 포맷간의 접착제로서 기능한다. 사용자들은 이러한 매핑을 직접 제어하거나 볼 수 없다.

WinFS Store는 또한 이전의 종래 파일 시스템에서의 그 파일 명칭과는 반대로, 그 타입에 기초하여 오브젝트를 질의하는 개념을 노출한다. 타입-기반 질의는 정확한 타입, 즉 주어진 타입으로부터 도출되는 임의의 타입을 검색할 수 있다. 이러한 후자의 형태는 계층적 매칭이라 불리고, 이는 공통 WinFS 오퍼레이션이 될 것으로 예상된다. WinFS는 또한 파일에 의한 검색을 지원한다.

WinFS의 스키마 모델은 질의 프로세서에 대해 일부 새로운 도전을 내포한다. 사용자 정의된 타입 또는 UDT는 광범위하게 이용되고, UDT 타입에 기초하여 테이블로부터 모든 UDT를 검색하는 것이 통상적이다. 또한, WinFS는 UDT 계승을 이용하고, 이는 테이블로부터 주어진 타입 및 또한 임의의 서브타입의 모든 요소를 검색하는 요구조건이다. 복수의 테이블이 존재하고, 각각은 다른 개수의 UDT, 타입, 타입 토폴로지(topology), 및 그 토폴리지내의 UDT 분포를 포함한다. 추가적으로, 검색 오퍼레이션은 예를 들면, XML 문서의 검색 또는 오브젝트내의 모든 필드에 걸친 검색의 수행을 포함하는 전통적인 관계형 데이터베이스 시스템에서 보여지는 그러한 오퍼레이션을 능가할 수 있다. 이들 속성들은 정확한 개수(cardinality) 및 비용 추정을 하기가 어렵게 만들고, 타입/서브타입 계층에 기초하여 값들을 효율적으로 검색하는 것을 어렵게 한다.

실체화 뷰(또한, 여기에서 인덱싱된 뷰로도 지칭됨)는 십년이상 데이터베이스 연구의 주제였다. 기본적인 아이디어는 일부 질의의 결과를 실체화하거나 저장한 후, 유사한 질의들이 데이터베이스에 제출되었을 때 그러한 계산된 결과를 이용하는 것이다. 예를 들어, 일일 판매액의 결과를 저장하고 장래에 그 결과(이러한 실체화 뷰)를 이용하여, 주어진 달의 판매액 또는 그 해의 총 판매액과 같은 수개의 관련된 질의에 답하는 것이 바람직하다.

추가적인 유연성을 위해, 어플리케이션은 특정 뷰가 존재하거나 실체화되어 있는 것을 인식할 필요는 없다. 질의 프로세서는 사용자 질의와 현존하는 미리-계산된 결과(실체화된 뷰)간의 매치를 식별하고, 적용가능한 경우에 그러한 결과를 이용한다. 이것은 뷰 활용 문제로서 알려져 있다. 실체화된 뷰의 집합뿐만 아니라, 베이스 테이블 상에 기록된 질의가 사용자에게 제공되는 경우, 그러한 질의에 답하는데 어떤 실체화된 뷰가 이용될 수 있을까? 그리고, 문제의 비용-기반 변동으로서, 이들 실체화된 뷰들 중 어느 것이 이용되어야 할 것인가? 등이다.

실체화된 뷰들은 데이터베이스의 물리적 디자인의 일부이고 그 주요 목적이 성능을 개선하는 것이라는 점에서, 인덱스와 유사하다. 데이터베이스의 논리적 디자인, 및 어플리케이션의 정확성은 실체화된 뷰의 존재 또는 부재와 무관하다. 인덱스에서와 같이, 실체화된 뷰는 질의 성능에서 엄청난 개선을 도입할 수 있다.

질의 옵티마이저는 도 1에 도시된 바와 같이, 정상적인 경우에, 초기의 단순화 스테이지가 존재하고, 이어서 대안의 조사, 및 실행 플랜의 비용-기반 선택이 따라오도록 구조화되어 진다.

단순화/정규화 스테이지(2) 동안에, 가능한 경우에, 선택을 푸시 다운하거나 서브질의를 결합(join)으로서 재기록하는 것과 같이, 원래의 질의 Q에 대해 일부 변경이 가해진다. 이들 변형들은 "더 나은" 질의를 얻는데 목표를 두고 있다. 통상, 이러한 스테이지에서는 상세화된 비용 추정이 없으며, 하나의 "더 나은" 질의 Q'가 결과로서 생성된다.

최적화의 제2 스테이지(5)(조사 및 비용-기반 선택)는 복수의 대안을 생성하는 것과 관련되고, 상세한 비용 모델을 이용하여 가장 저렴한 추정 실행 비용을 가 지는 대안을 선택하는 것이다. 조사 스테이지에 대한 2개의 종래 아키텍쳐는 아래에서-위로, 다이나믹 프로그래밍 결합 열거(enumeration), 및 변환-구동형의 대안 생성이다. 양쪽 아키텍쳐는 공지된 바와 같이, 대안의 테이블을 셋업하고, 이는 질의의 각-서브 표현에 대한 다양한 가능성을 컴팩트하게 인코딩한다.

조사동안에 실체화된 뷰를 고려하는 것은 그러한 실체화된 뷰를 이용하는 엔트리로 대안 테이블을 증가시키는 것을 포함한다. 원래의 질의가 테이블 A, B, C 상의 결합이라고 가정하자. 물리적 대안들(논리적 오퍼레이터만을 가짐)은 이하와 같이 주어진다.

인코딩된 오퍼레이터 트리는 대안 테이블을 횡단하고, 루트 엔트리(상기 질의에서 ABC)에서 시작하며, 각 엔트리에서 오퍼레이터를 선택함으로써 얻어진다. 예를 들어, 각 엔트리에서 제1 선택을 취함으로써, 도 2에 도시된 오퍼레이터 트리(10)가 얻어진다.

이제, 실체화된 뷰

라고 가정하자. 이것은 A 및 B의 결합의 결과를 포함하는 Vt로서 지칭되는 저장된 테이블이 있다는 것을 의미한다. 이것은 결합 서브-표현을 얻는 유효한 방식이므로, 대안들은 이러한 대안으로 증가되어, 이하와 같이 된다.

옵티마이저에 의해 생성될 수 있고 고려될 수 있는 유효한 오퍼레이터 트리(13)가 도 3에 도시되어 있다.

대안 테이블을 증가시키는 메커니즘은 옵티마이저 아키텍쳐에 달려있다. 변환-기반 옵티마이저의 경우에, 새로운 변환 규칙을 시스템에 부가함으로써 확장이 얻어지고, 아래에서-위로 결합 열거에 대해, 구성 절차가 변경되어야 한다. 대안이 테이블에 부가된 후, 비용을 추정하고, 고가의 해결책을 잘라내며, 오퍼레이터 트리를 조립하고 최적의 해결책을 구성하는 정상적인 옵티마이저 메커니즘이 적용된다.

거래 정확성을 보장하기 위해, 실체화된 뷰의 컨텐트는 베이스 테이블의 변경에 대해 동기가 유지되어야 한다. 예를 들어, 주문이 입력되거나 변형되는 경우, 주당 판매액의 실체화는 변경을 반영하기 위해 업데이트되어야 한다. 이것은 뷰 유지보수 문제로서 알려져 있다. 환언하면, 베이스 테이블의 기저 데이터가 변경되면, 실체화된 뷰에서도 변경이 수행되어야 한다. 전체 실체화된 뷰는 재계산 시간 및 비용으로 인해 그러한 변경을 반영하도록 재-계산될 필요가 없는 것이 바람직하다.

현재의 데이터 저장 및 데이터베이스 기술에서의 상기 문제점들을 감안하여, 실체화된 뷰의 효율적인 이용이 필요하다. 본 발명은 이러한 필요성을 만족시킨다.

이하의 요약은 본 발명의 다양한 양태들의 개관을 제공한다. 본 발명의 중요한 모든 양태들의 소모적 기술을 제공하려는 것이 아니고, 또한 본 발명의 범주를 정의하려는 것도 아니다. 오히려, 이러한 요약은 이하의 상세한 설명 및 도면에 대한 소개로서 기능하려는 것이다.

본 발명은 잠재적으로 멀티-값으로 된 속성을 가지는 베이스 테이블상의 제2 인덱스로서 실체화된 뷰(여기에서, 인덱싱된 뷰로도 지칭됨)의 이용에 관한 것이다. 이것은 인덱스를 이용하여 데이터에 대한 함수 적용의 결과를 검색하는 것을 제공한다. 더구나, 본 발명은 테이블-값으로 된 함수 호출의 결과에 대해 인덱싱하는 것을 제공한다. 그러한 함수 호출의 결과에 대해 뷰를 인덱싱하는 것은 복잡한 구조의 컨텐트를 인덱싱하는 능력을 제공한다.

예시적인 언네스팅(unnesting) 오퍼레이션은 "크로스 어플라이 언네스트(cross apply unnest)"이다. 이러한 예에서, UNNEST는 UDT 집합(collection)을 복잡한 구조로서 취하고 집합에서 각 요소에 대한 로우(row)를 출력하는 함수이다. 다른 함수 예는 XML 데이터를 더 검색가능한 형태로 변환하거나 복수의 칼럼을 전용 검색을 위해 하나의 인덱싱 구조로 분해할 수 있다. 이러한 발명은 질의 실행 플랜에 대한 추가적인 옵션을 제공하여, 더 최적화된 질의를 유도한다.

본 발명의 추가 양태에 따르면, 후방-결합(back-join)은 인덱싱된 뷰로부터 베이스 테이블에 제공된다. 이것은 인덱싱된 뷰에 존재하지 않는 베이스 테이블로부터의 필드가 인덱싱된 뷰를 액세스 경로로서 이용하여 처리되는 테이블 상의 질의 결과에 포함될 수 있게 한다. 이것은 인덱싱되지 않고 베이스 테이블내에 있는 질의 결과에 칼럼을 포함하는 수단을 제공한다. 후방-결합은 논리적 로우 로케이터로서 작용하는 고유 클러스터링 키를 통해 하나의-테이블 인덱싱된 뷰로부터 베이스 테이블로 지원된다. 그러므로, 시스템은 고유 클러스터링 키를 통해 인덱싱된 뷰로부터 베이스 테이블에 후방-결합될 수 있다. 이들 특징들은 인덱싱된 뷰들의 이용이 복잡한 함수 호출의 컨텐트 상의 테이블을 인덱싱할 수 있게 하고, 이러한 함수 호출을 통해 기준을 매칭하는 로우로부터 데이터를 효율적으로 검색할 수 있게 한다.

본 발명의 다른 특징 및 장점들은 본 발명 및 첨부된 도면의 이하의 상세한 설명으로부터 명백하게 될 것이다.

이하의 양호한 실시예의 상세한 설명뿐만 아니라, 상기 요약은 첨부된 도면과 함께 읽어질 때 더 잘 이해될 것이다. 본 발명을 예시할 목적으로, 도면에 본 발명의 예시적인 구성이 도시되어 있지만, 본 발명은 개시된 특정 방법 및 수단으로 제한되지 않는다.

도 1은 종래 질의 옵티마이저의 블록도.

도 2는 예시적인 오퍼레이터 트리의 도면.

도 3은 실체화된 뷰를 포함하는 도 2의 오퍼레이터 트리의 도면.

도 4는 본 발명의 양태들이 실시되는 컴퓨터 시스템을 표시한 블록도.

도 5는 3개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트, 오퍼레이팅 시스템 컴포넌트, 및 어플리케이션 프로그램 컴포넌트로 분할된 컴퓨터 시스템을 예시한 블록도.

도 6은 폴더로 그룹화된 파일에 대한 트리-기반 계층적 구조를 예시하는 도면.

도 7은 본 발명과 함께 이용될 수 있는 저장 플랫폼의 예시적인 도면.

도 8은 본 발명에 따라 인덱싱된 뷰의 예시적인 도면.

도 9는 본 발명에 따른 클러스터링 키의 예시적인 도면.

도 10은 본 발명에 따른 실행 플랜의 예시적인 도면.

도 11은 본 발명에 따른 액세스 플랜의 예시적인 도면.

도 12는 본 발명에 따라 데이터를 질의하는 방법의 예에 대한 흐름도.

주제는 법적 조건을 충족시키도록 구체적으로 기재된다. 그러나, 기재 자체는 본 발명의 범주를 제한하려는 것이 아니다. 오히려, 발명자들은 다른 현재 또는 미래 기술과 조합하여 다른 단계 또는 본 명세서에 기재된 것들과 유사한 단계들의 조합을 포함하여 청구된 주제들이 다른 방식으로 실시될 수 있다고 생각했다. 더구나, 용어 "단계"는 여기에서 채용된 다른 방법의 요소들을 의미하는데 이용되지만, 상기 용어는 개별적인 단계들의 순서가 명백하게 기재되지 않은 경우 또는 그 때를 제외하고는 여기에 공개된 다양한 단계들 사이에 임의의 특별한 순서를 암 시하는 것으로 해석되어서는 안된다.

WinFS는 파일 시스템에서 오브젝트의 개념을 도입하는 파일 시스템/데이터 스토어이다. 이러한 스토어의 오퍼레이션들 중 하나는 오브젝트를 효율적으로 로케이팅하고 질의할 수 있는 것이다. 본 발명은 이러한 오퍼레이션의 양태들이 매우 효율적으로 만들어지는 방법을 기재하고 있다.

컴퓨팅 환경의 예

본 명세서 및 청구의 범위에 이용될 때, 이하의 용어들은 이하의 의미를 가지고 있다.

"오브젝트"는 하드웨어/소프트웨어 인터페이스 시스템 셸에 의해 최종 사용자에게 노출되는 모든 오브젝트에 걸쳐 공통으로 지원되는 기본 속성 세트를 가지는 하드웨어/소프트웨어 인터페이스 시스템에 액세스 가능한 저장가능한 정보 단위이다. 오브젝트는 또한 새로운 속성 및 관계가 도입될 수 있도록 허용하는 특징을 포함하는 모든 타입에 걸쳐 통상 지원되는 속성 및 관계를 가지고 있다.

"오퍼레이팅 시스템(OS)"은 어플리케이션 프로그램과 컴퓨터 하드웨어간의 중재자로서 작용하는 특별한 프로그램이다. 오퍼레이팅 시스템은 대부분의 경우에 쉘 및 커널을 포함한다.

"하드웨어/소프트웨어 인터페이스 시스템"은 컴퓨터 시스템의 기저 하드웨어 컴포넌트와 컴퓨터 시스템 상에서 실행되는 어플리케이션간의 인터페이스로서 기능하는 소프트웨어, 또는 하드웨어와 소프트웨어의 조합이다. 하드웨어/소프트웨어 인터페이스 시스템은 통상 오퍼레이팅 시스템을 포함한다(일부 실시예의 경우에는, 오퍼레이팅 시스템만으로 구성된다). 하드웨어/소프트웨어 인터페이스 시스템은 컴퓨터 시스템에서 오퍼레이팅 시스템 대신에 또는 그에 추가하여, 가상 머신 매니저(VMM), 공통 언어 런타임(CLR) 또는 그 기능적 등가물, 자바 가상 머신(JVM) 또는 그 기능적 등가물, 또는 다른 그러한 소프트웨어 컴포넌트를 포함한다. 하드웨어/소프트웨어 인터페이스 시스템의 목적은 사용자가 어플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의의 하드웨어/소프트웨어 인터페이스 시스템의 목적은 컴퓨터 하드웨어를 효율적인 방식으로 활용하게 할 뿐만 아니라, 컴퓨터 시스템을 이용하기 편하게 하는 것이다.

본 발명의 다수의 실시예들은 컴퓨터 상에서 실행될 수 있다. 도 4 및 이하의 설명은 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경의 간단하고 일반적인 설명을 제공하려는 것이다. 요구되지는 않지만, 본 발명은 클라이언트 워크스테이션 또는 서버와 같이, 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령어들의 일반적인 컨텍스트로 기재될 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상적인 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 더구나, 본 기술분야의 숙련자라면, 본 발명은 핸드헬드 디바이스, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하여, 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 잘 알고 있을 것이다. 본 발명은 통신 네트워크를 통해 링크되는 원격 처리 디바이스에 의해 태스크들이 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 디바이스에 모두 위치될 수 있다.

도 4에 도시된 바와 같이, 예시적인 범용 컴퓨팅 시스템은 처리 유닛(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)뿐만 아니라, 퍼스널 컴퓨터는 스피커 및 프린터와 같은 다른 주변장치 출력 디바이스(도시되지 않음)를 포함할 수 있다. 도 4의 예시적인 시스템은 호스트 어댑터(55), SCSI 버스(56), 및 SCSI 버스(56)에 접속되는 외부 저장 디바이스(62)를 포함한다.

퍼스널 컴퓨터(20)는 원격 컴퓨터(49)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워킹된 환경에서 동작할 수 있다. 원격 컴퓨터(49)는 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스 또는 다른 공통 네트워크 노드일 수 있고, 도 4에는 단지 메모리 저장 디바이스(50)만이 예시되어 있지만, 통상 퍼스널 컴퓨터(20)와 관련하여 상기 설명한 구성요소들 중 다수 또는 모두를 포함한다. 도 4에 도시된 논리적 접속은 LAN(51) 및 WAN(52)를 포함한다. 그러한 네트워킹 환경은 사무실, 기업-광역 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

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

본 발명의 다수의 실시예들이 컴퓨터화된 시스템에 특히 잘 적합하도록 고안되었지만, 본 문서의 어떤 것도 본 발명을 그러한 실시예로 제한하려는 것은 아니다. 이에 반해, 여기에 이용되는 바와 같이, "컴퓨터 시스템"은 그러한 디바이스가 전자적, 기계적, 논리적 또는 본질적으로 가상적인지 여부에 관계없이, 누름 버 튼을 포함하거나, 버튼 누름을 결정할 수 있거나 버튼 누름의 등가를 포함하는 임의의 및 모든 디바이스를 포함하려는 것이다.

도 5의 블록도에 예시된 바와 같이, 컴퓨터 시스템(200)은 대략 3개의 컴포넌트 그룹, 즉 하드웨어 컴포넌트(202), 오퍼레이팅 시스템 컴포넌트(204) 및 어플리케이션 프로그램 컴포넌트(206)로 분할될 수 있다.

특정 컴퓨터 시스템(200)에서, 도 4를 다시 참조하면, 하드웨어(202)는 다른 것들중에서 중앙 처리 유닛(CPU, 21), 메모리(ROM(24) 및 RAM(25)), 기본 입출력 시스템(BIOS, 26), 및 키보드(40), 마우스(42), 모니터(47) 및/또는 프린터(도시되지 않음)와 같은 다양한 입출력(I/O) 디바이스를 포함한다. 하드웨어 컴포넌트(202)는 컴퓨터 시스템(200)에 대한 기본적인 리소스를 포함한다.

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

오퍼레이팅 시스템 컴포넌트(204)는 오퍼레이팅 시스템 자체와 그 쉘 및 커널을 포함한다. 오퍼레이팅 시스템(OS)은 어플리케이션 프로그램과 컴퓨터 하드웨어간의 중간 매개자로서 기능하는 특별 프로그램이고, 오퍼레이팅 시스템의 목적은 사용자가 어플리케이션 프로그램을 실행할 수 있는 환경을 제공하는 것이다. 임의 의 오퍼레이팅 시스템의 목적은 컴퓨터 하드웨어를 효율적으로 활용할 뿐만 아니라 컴퓨터 시스템을 이용하기 편하게 하는 것이다.

오퍼레이팅 시스템은 일반적으로 컴퓨터 시스템 시동시 로딩되고, 그런 다음, 컴퓨터 시스템내의 모든 어플리케이션 프로그램(또는 단순히 "어플리케이션")을 관리한다. 어플리케이션 프로그램은 어플리케이션 프로그램 인터페이스(API)를 통해 서비스를 요구함으로써 오퍼레이팅 시스템과 상호작용한다. 일부 어플리케이션 프로그램은 최종 사용자들이 명령 언어 또는 그래픽 사용자 인터페이스(GUI)와 같은 사용자 인터페이스를 통해 오퍼레팅 시스템과 상호작용할 수 있게 한다.

오퍼레이팅 시스템은 전통적으로 어플리케이션에 대해 다양한 서비스를 수행한다. 복수의 프로그램이 동시에 실행되고 있는 멀티태스킹 오퍼레이팅 시스템에서, 오퍼레이팅 시스템은 어느 어플리케이션이 어떤 순서로 운용될지 및 전환을 위해 다른 어플리케이션으로 스위칭하기 이전에 각 어플리케이션에 대해 얼마나 많은 시간이 허용되는지를 결정한다. 오퍼레이팅 시스템은 복수의 어플리케이션 중에서 내부 메모리의 공유를 관리하고, 하드 디스크, 프린터 및 다이얼-업 포트와 같은 부착된 하드웨어 디바이스로의 입력 및 출력을 핸들링한다. 오퍼레이팅 시스템은 또한 오퍼레이션 상태 및 발생될 수 있는 임의의 에러에 관하여 메시지를 각 어플리케이션에(그리고, 어떤 경우에는 최종 사용자에게) 전송한다. 오퍼레이팅 시스템은 개시하는 어플리케이션이 이러한 작업으로부터 자유롭게 되도록 배치(batch) 작업(예를 들면, 프린팅)의 관리를 오프로딩할 수 있고, 다른 처리 및/또는 오퍼레이션을 재개할 수 있다. 병렬 처리를 제공할 수 있는 컴퓨터 상에서, 오퍼레이팅 시스템은 한번에 하나 이상의 프로세서 상에서 운용되도록 프로그램을 분할하여 관리한다.

오퍼레이팅 시스템의 쉘은 오퍼레이팅 시스템으로의 인터액티브한 최종 사용자 인터페이스이다(그리고, "명령 해석기"로도 알려짐). 쉘은 어플리케이션 프로그램에 의해 바로 액세스가능하고 심지어 최종 사용자에 의해 액세스가능한 오퍼레이팅 시스템의 외부 계층이다. 셀과는 반대로, 커널은 하드웨어 컴포넌트와 바로 상호작용하는 오퍼레이팅 시스템의 최내곽 계층이다.

본 기술분야의 숙련자들이라면 잘 알고 있는 바와 같이, "파일"은 오퍼레이팅 시스템에 의해 구체적(저장가능하고 검색가능한) 실체로서 조작될 수 있는 정보의 실체(어플리케이션 프로그램, 데이터 세트 뿐만 아니라, 오퍼레이팅 시스템 자체를 포함하고 이들로 제한되지 않음)이다. 현대의 오퍼레이팅 시스템(윈도우즈, 유닉스, 리눅스, 맥 OS, 등)에서, 파일은 오퍼레이팅 시스템에 의해 조작되는 저장가능한 정보(예를 들면, 데이터, 프로그램 등)의 기본적인 유닛이고, 파일의 그룹들은 "폴더"로 조직화된다. 마이크로소프트 윈도우즈, 맥킨토시 및 다른 오퍼레이팅 시스템에서, 폴더는 검색되고, 이동되며 다르게는 하나의 실체로서 조작될 수 있는 파일 집합이다. DOS, z/OS 및 대부분의 유닉스 기반 오퍼레이팅 시스템과 같은 특정 다른 오퍼레이팅 시스템에서, 용어 "디렉토리"가 폴더보다 이용되고, 이전에 애플 컴퓨터 시스템(예를 들면, Apple IIe)은 용어 "카탈로그"를 이용했지만, 여기에 이용되는 바와 같이, 이들 모든 용어들은 동의어로서 상호 교환가능하고, 여기에서 계층적 정보 저장 구조에 대한 모든 다른 등가 용어 및 참조들을 더 포함 하려는 것이다.

본 기술분야의 숙련자들에게 공지되어 있는 바와 같이, 디렉토리(즉, 폴더의 디렉토리)는 트리 구조의 노드를 포함하는 폴더에서의 위치에 기초하여 파일이 그룹화되는 트리-기반 계층적 구조이다. 예를 들어, 도 6에 예시된 바와 같이, DOS-기반 파일 시스템 베이스 폴더(또는, "루트 디렉토리", 302)는 복수의 폴더(304)를 포함하고, 이들 각각은 추가 폴더(그 특정 폴더의 "서브폴더"로서, 306)를 더 포함하며, 이들 각각은 추가 폴더(308)를 영구히 포함할 수 있다. 오퍼레이팅 시스템 레벨에서, 이들 각 폴더들은 하나 이상의 파일(310)을 가지고 있지만, 폴더의 개별적인 파일들은 트리 계층에서 그 위치 이외에 공통으로 갖는 것이 없다. 이러한 파일을 폴더 계층으로 구성하는 접근법은 이들 파일을 저장하는데 이용되는 전형적인 저장 매체(예를 들면, 하드 디스크, 플로피 디스크, CD-ROM, 등)의 물리적 조직을 간접적으로 반영한다는 것은 놀라만한 것은 아니다.

상기 뿐만 아니라, 각 폴더는 그 서브 폴더 및 그 파일에 대한 컨테이너이고, 즉 폴더는 이들 서브폴더 및 파일을 소유한다. 예를 들어, 폴더가 오퍼레이팅 시스템에 의해 삭제되면, 그 서브폴더 및 파일도 삭제된다(각 서브폴더의 경우에, 그 자신의 서브폴더 및 파일을 반복적으로 포함함). 마찬가지로, 각 파일은 하나의 폴더에 의해서만 소유될 수 있고, 파일이 복사될 수 있고 복사본이 다른 폴더에 위치될 수 있지만, 파일의 복사본 자체는 원본과의 직접적인 관련을 가지지 않는 개별적이고 분리된 실체이다(예를 들어, 원래 파일의 변경은 오퍼레이팅 시스템 레벨에서 복사본 파일에 반영되지 않는다). 이러한 측면에서, 폴더는 물리적 컨테이 너의 개념적 등가이고 파일은 컨테이너 내부의 이산적이고 분리된 물리적 요소와 개념적 등가물이므로, 파일 및 폴더는 그 본질적으로 특징상 "물리적"이다.

본 발명과 함께 이용될 수 있는 데이터를 구성하고, 검색하며 공유하기 위한 저장 플랫폼은 오브젝트라 불리는 데이터 형태를 포함하는 모든 타입의 데이터에 대한 스토어가 되도록 설계된다. 도 7을 참조하면, 본 발명에 따른 저장 플랫폼(400)은 데이터베이스 엔진(414) 상에 구현되는 데이터 스토어(402)를 포함한다. 하나의 실시예에서, 데이터베이스 엔진은 오브젝트 관계형 확장을 가지는 관계형 데이터베이스 엔진을 포함한다. 하나의 실시예에서, 관계형 데이터베이스 엔진(414)은 마이크로소프트 SQL 서버 관계형 데이터베이스 엔진을 포함한다.

데이터 스토어(402)는 데이터의 구성, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델(404)을 구현한다. 특정 타입의 데이터는 스키마(440)와 같은 스키마에 기술되고, 저장 플랫폼(400)은 이들 스키마를 확장하기 위한 것뿐만 아니라 이들 스키마를 전개하기 위한 툴(446)을 제공한다.

데이터 스토어(402)내에 구현되는 변경 추적 메커니즘(406)은 데이터 스토어의 변경을 추적하는 능력을 제공한다. 데이터 스토어(402)는 보안 능력(408) 및 프로모션/디모션 능력(410)을 제공한다. 데이터 스토어(402)는 또한 데이터 스토어(402)의 능력을 저장 플랫폼을 활용하는 다른 저장 플랫폼 컴포넌트 및 어플리케이션 프로그램(예를 들면, 어플리케이션 프로그램(450a, 450b, 450c))에 노출시키는 어플리케이션 프로그래밍 인터페이스(412) 세트를 제공한다.

본 발명의 저장 플랫폼은 어플리케이션 프로그램(450a, 450b 및 450c)과 같 은 어플리케이션 프로그램이 저장 플랫폼의 상기 모든 능력에 액세스할 수 있게 하고 스키마에 기재된 데이터에 액세스할 수 있도록 하는 어플리케이션 프로그래밍 인터페이스(API, 422)를 더 포함한다. 저장 플랫폼 API(422)는 OLE DB API(424) 및 마이크로소프트 윈도우즈 Win32 API(426)과 같은 다른 API와 조합하여 어플리케이션 프로그램에 의해 이용될 수 있다.

본 발명의 저장 플랫폼(400)은 사용자 또는 시스템 사이에서 데이터의 공유를 용이하게 하는 동기화 서비스(430)를 포함하여, 다양한 서비스(428)를 어플리케이션 프로그램에 제공할 수 있다. 예를 들어, 동기화 서비스(430)는 다른 포맷을 가지는 데이터 스토어(442)로의 액세스뿐만 아니라, 데이터 스토어(402)와 동일한 포맷을 가지는 다른 데이터 스토어(440)와의 상호운용성을 가능하게 한다. 저장 플랫폼(400)은 또한 윈도우즈 NTFS 파일 시스템(418)과 같은 현재의 파일 시스템과 데이터 스토어(402)의 상호운용성을 허용하는 파일 시스템 능력을 제공한다.

적어도 일부 실시예에서, 저장 플랫폼(420)은 어플리케이션 프로그램에, 데이터가 작용될 수 있게 하고 다른 시스템과의 인터액션을 가능하게 하기 위한 추가 성능을 제공한다. 이들 성능들은 다른 유틸리티(436)의 형태로뿐만 아니라, 정보 에이전트 서비스(434) 및 통지 서비스(432)와 같은 추가 서비스(428)의 형태로 실시될 수 있다.

적어도 일부 실시예들에서, 저장 플랫폼은 컴퓨터 시스템의 하드웨어/소프트웨어 인터페이스 시스템으로 실시되거나, 이의 통합 부분을 형성한다. 예를 들면, 이들로 제한되지 않고, 본 발명의 저장 플랫폼은 오퍼레이팅 시스템, 가상 머신 매 니저(VMM), 공통 언어 런타임(CLR) 또는 그 기능적 등가물, 또는 자바 가상 머신(JVM) 또는 그 기능적 등가물로 실시되거나 이들의 통합 부분을 형성한다.

그 공통 저장 기반 및 스키머타이징된 데이터를 통해, 본 발명의 저장 플랫폼은 소비자, 지식 노동자, 및 기업에 대해 더 효율적인 어플리케이션 개발을 가능하게 한다. 이는 그 데이터 모델에 고유한 성능을 가용하게 할 뿐만 아니라 현재의 파일 시스템 및 데이터베이스 액세스 방법을 포함하고 확장하는 풍부하고 확장가능한 프로그래밍 표면 영역을 제공한다.

여기의 설명에서, 그리고 도면들중 다양한 것들에서, 본 발명의 저장 플랫폼(400)은 "WinFS"로 지칭될 수 있다. 그러나, 저장 플랫폼을 지칭하는데 이러한 명칭의 이용은 단지 설명의 편의성을 위한 것이고, 어떤 방식으로든 제한적이려는 것이 아니다.

본 발명의 저장 플랫폼(400)의 데이터 스토어(402)는 스토어에 상주하는 데이터의 조직, 검색, 공유, 동기화 및 보안을 지원하는 데이터 모델을 구현한다. 본 발명의 데이터 모델에서, "오브젝트"는 저장 정보의 기본 단위이다. 데이터 모델은 오브젝트 및 오브젝트 확장을 선언하고 오브젝트간 관계를 확립하며 오브젝트를 조직하고 카테고리화하기 위한 메커니즘을 제공한다.

하나의 실시예에서 마이크로소프트 SQL 서버 엔진을 포함하는 관계형 데이터베이스 엔진(414)은 내장형(built-in) 스칼라 타입을 지원한다. 내장형 스칼라 타입은 "선천적이고(native)" "간단하다". 이들은 사용자가 그 자신의 타입을 정의할 수 없다는 의미에서 선천적이고, 이들이 복잡한 구조를 캡슐화할 수 없다는 의 미에서 단순하다. 사용자-정의된 타입("UDT")은 복잡하고 구조화된 타입을 정의하여 사용자가 타입 시스템을 확장할 수 있도록 함으로써 선천적인 스칼라 타입 시스템을 넘는 타입 확장성에 대한 메커니즘을 제공한다. 일단 사용자에 의해 정의되면, UDT는 내장형 스칼라 타입이 이용될 수 있는 타입 시스템 내의 어느 곳에서도 이용될 수 있다.

저장 플랫폼 스키마는 데이터베이스 엔진 스토어에서 UDT 클래스에 매핑된다. 데이터 스토어 오브젝트는 Base.Item 타입으로부터 도출되는 UDT 클래스에 매핑된다. 확장은 UDT 클래스에 매핑되고 계승을 이용한다. 루트 확장 타입은 Base.Extenstion이고, 모든 확장 타입이 이로부터 도출된다.

UDT는 CLR 클래스이고, 이는 상태(즉, 데이터 필드) 및 거동(즉, 루틴)을 가지고 있다. UDT는 관리된 언어-C#, VB.NET 등 중 어느 것을 이용하여 정의된다. UDT 방법 및 오퍼레이터는 그 타입의 인스턴스에 대하여 T-SQL에서 호출될 수 있다. UDT는 예를 들면, 로우에서 칼럼의 타입, T-SQL에서 루틴의 파라미터의 타입, 또는 T-SQL에서 변수의 타입이 될 수 있다.

실시예

본 발명은 베이스 테이블로서 알려진 테이블 상에서 인덱싱된 뷰(즉, 실체화된 뷰)의 생성을 제공하고(그것은 뷰가 정의되는 베이스이므로), 이러한 인덱싱된 뷰를 질의를 향상하는데 이용될 수 있는 추가 오퍼레이션 및 구조에서 이용한다. 인덱싱된 뷰는 베이스 테이블 상의 인덱스로서 기능한다. 이러한 인덱스는 베이스 테이블로서의 액세스 경로로서 이용되어, 인덱싱된 뷰의 구조 및 베이스 테이블과 매칭하는 질의를 해결한다.

전형적인 인덱싱된 뷰는 데이터 엔트리를 포함하고, 연관된 서브-엔트리 또는 다른 종속되거나 도출된 데이터를 포함할 수 있다. 인덱싱된 뷰는 데이터를 변환하는 함수 호출의 결과를 포함할 수 있다. 하나의 예로서, 인덱싱된 뷰는 네스팅(nesting)을 포함하고, 이 경우에 하나의 엔트리는 복수의 연관된 서브-엔트리를 가지고 있다. 예를 들면, 제1 베이스 테이블이 이름을 포함하고, 제2 베이스 테이블이 어드레스를 포함하고 있다고 가정하자. 2개의 베이스 테이블에 대한 "결합" 오퍼레이션은 특정 이름에 대한 어드레스를 제공한다. 도 8에 도시된 인덱싱된 뷰(500)와 같이, 이름 및 연관된 어드레스를 포함하는 인덱싱된 뷰가 저장될 수 있다. 인덱싱된 뷰(500)에서, 이름 "Alice"는 3개의 연관된 어드레스, 즉, 어드레스 1, 어드레스 2, 및 어드레스 3을 가지고 있다. 예시적인 인덱싱된 뷰(500)에서 다른 이름(예를 들면, "Bob" 및 "Charlie")은 각각 하나의 연관된 어드레스를 가지고 있다. 인덱싱된 뷰는 이름 "Alice"와 연관된 복수의 어드레스로 인해 네스팅된 것으로 간주된다. 이러한 네스팅을 제거하는 것이 바람직하므로, Alice와 연관된 어드레스 중 하나가 변경된다면, 어드레스가 직접 액세스될 수 있고, 인덱싱된 뷰는 변경을 반영하기 위해 재-계산될 필요는 없다. 다른 함수의 결과들은 이와같이 인덱싱될 수도 있다.

이러한 네스팅을 제거하기 위해, 도 9에 도시된 바와 같이, 고유 클러스터링 키(550)가 구축된다. 이하에 더 상세하게 도시되고 설명되는 바와 같이, 키(550)는 인덱싱된 뷰에 네스팅을 가지는 각 엔트리에 대해 분리된 서브-엔트리를 제공한 다. 그러므로, 이러한 예에서의 키(550)는 3개의 엔트리 "Alice"를 제공하고, 각각은 어드레스들, 어드레스 1, 어드레스 2, 및 어드레스 3 중 다른 하나와 연관된다. 이러한 키는 어플리케이션이 베이스 테이블과 인덱싱된 뷰 사이에서 앞뒤로 이동할 수 있도록 한다.

인덱싱된 뷰는 복수의 값으로 된 속성을 가지는 베이스 테이블상의 제2 인덱스로서 다루어질 수 있다. 그러므로, 본 발명은 인덱싱된 뷰를 이용하여 함수 호출의 결과(예를 들면, 본 예에서는 네스팅된 데이터)에서 검색하는 것을 제공한다. 인덱싱은 함수 호출의 결과에 대해 수행딘다. 환언하면, 도출된 데이터(즉, 서브-엔트리)가 인덱싱된다. 본 발명은 복잡한 구조를 인덱싱함으로써, 더 많은 인덱싱된 뷰들이 결정되어 가용하게 될 수 있다. 이것은 질의 실행 플랜에 대해 더 많은 옵션을 제공하고, 더 최적화된 질의를 유도한다.

이하에 더 설명되는 바와 같이, 함수 호출 오퍼레이션의 결과에 대해 뷰를 인덱싱하는 것은 데이터(예를 들면, 네스팅된 집합의 컨텐트)의 복합 변환을 인덱싱하는 방법을 제공한다. 본 발명에 의해 지원되는 예시적인 언네스팅 오퍼레이션은 SQL 서버의 "크로스 어플라이 언네스트(cross apply unnest)"이다. 특히, "크로스 어플라이 언네스트" 오퍼레이션시, 인덱싱된 뷰에서 네스팅된 하나의 레벨이 언네스팅될 수 있다. 그러나, 본 발명에 따르면 임의 개수의 언네스팅 레벨이 이용될 수 있다는 것은 자명하다. 더 일반적으로는, 복수 레벨의 함수 호출이 이러한 방식으로 인덱싱될 수 있다는 것은 자명하다.

더구나, "후방-결합"은 인덱싱된 뷰로부터 베이스 테이블로 제공된다. 이것 은 인덱싱된 뷰에 존재하지 않는 베이스 테이블로부터의 필드가, 액세스 경로로서 인덱싱된 뷰를 이용하여, 처리되는 테이블 상의 질의 결과에 포함될 수 있게 한다. 후방-결합은 인덱싱된 뷰로부터 뷰가 정의되는 베이스 테이블에 이용된다. 이것은 인덱싱된 뷰에 있는 것이 아니라 베이스 테이블에 있는 질의 결과에 칼럼을 포함시키는 수단을 제공한다.

후방-결합은 논리적 로우 로케이터로서 작용하는 고유 클러스터링 키를 통해, 단일 테이블 인덱싱된 뷰로부터 베이스 테이블에 지원되는 것이 바람직하다. 시스템은 고유 클러스터링 키를 통해 인덱싱된 뷰로부터 베이스 테이블에 후방 결합할 수 있다. 이러한 특징들은 복수-세트 또는 복수 값으로된 속성에 대한 "크로스 어플라이 언네스트" 오퍼레이션과 같이, 인덱싱된 뷰의 이용이 데이터에 대한 함수 호출의 결과의 컨텐츠에 대해 테이블을 인덱싱할 수 있게 한다.

상기 언급된 바와 같이, 인덱싱된 뷰는 데이터에 대한 함수 호출(예를 들면, 크로스 어플라이 언네스트 오퍼레이션)의 결과에 대해 정의될 수 있다. 후방-결합 성능과 조합하여, 이것은 이들 레코드(record)에 포함된 값들의 집합의 컨텐츠에 기초하여 테이블의 레코드의 액세스를 허용한다. 그러므로, UDT의 복수-세트 속성 상의 인덱스는 인덱싱된 뷰를 이용하여 생성될 수 있다. 예를 들어, 이하의 인덱싱된 뷰는 도시의 검색 성능의 속도를 향상시키는데 도움을 줄 수 있다.

유의할 점은, addrID 및 pid는 인덱스를 고유하게 하는데 이용되는 것이 바 람직하다는 점과, addrID는 하나의 어드레스 복수 세트내에서 고유하다고 가정된다는 것이다. 이하의 예는 일반적인 함수 호출이 이러한 인덱싱 성능에서 가능할 수 있는 방법을 증명하고 있다.

이러한 예에서, "언네스트(unnest)"는 여기에서 설명된 "데이터에 대한 함수 호출"을 나타내는 "FUNCTION"으로 대체되었다. 일반적으로, "FUNCTION" 대신에 다른 함수들이 이용될 수 있다. 가능한 예들은 집합 내의 데이터를 언네스팅하고, XML 문서를 분해하거나, 복잡한 구조(예를 들면, UDT)로부터 복수의 필드를 인덱싱하는 것을 포함한다. 물론 데이터에 대한 다른 함수에 대해 이러한 메커니즘을 이용하는 것도 가능하다.

질의에 대한 인덱싱된 뷰는 베이스 테이블(예를 들면, 베이스 테이블 "person")을 읽지 않고 질의에 답하는데 이용될 수 있다. 이것은 인덱스가 베이스 테이블보다 훨씬 더 작을 수 있으므로 유익하다. 예를 들어, 베이스 테이블 "person"은 UDT인 속성 pcol을 포함하는 것이 바람직하다. pcol의 필드 중 하나(어드레스)는 복수-세트(집합-값으로 된 속성)이다. 가상적인 "person" 테이블인 표 1을 참조하라.

표 1은 가장 미세한 입도 레벨을 도시하고 있다. 상기 예에 필수적이지 않은 칼럼들은 생략되었고 타원으로 도시되어 있다. 본 예에서, pid 및 name은 원자 속성이고 따라서 단지 하나의 값을 포함하지만, address는 집합이므로 하나 이상의 값을 포함하고 있다는 것에 주목하라. City는 address의 각 멤버의 필드이다.

"person" 테이블에서, 각 name에 대해 복수의 서브-로우가 도시되어 있다. 예를 들면, Bob은 각각 Bellevue 및 Corvallis에 대응하는 2개의 어드레스 서브-로우, 즉 AddrID 1 및 2를 가지고 있고, Sue는 각각 Bellevue 및 Berkeley에 대응하는 2개의 어드레스 서브-로우, 즉 AddrID 3 및 4를 가지고 있다.

인덱싱된 뷰 iv_city를 보자. "person" 테이블의 상기 값에 대해, iv_city의 컨텐트는 표 2에 도시된 바와 같다.

iv_city의 각 로우는 가장 미세한 입도 레벨 데이터에서의 정보에 대응한다. 그러므로, 인덱싱된 뷰는 각 서브-로우 엔트리가 그 자신의 로우에 현재 있다는 것을 보여주고 있다. Pid는 다시 제1 테이블로의 후방-결합으로서 이용될 수 있다는 점에 유의하라. 예를 들어, iv_city의 Pid 1은 "person" 테이블의 Pid 1에 후방 결합할 것이다. 부분적인 데이터(즉, 관심이 있는 데이터만, 예를 들어 Bellevue에 사는 사람들만)를 인덱싱할 수 있다.

이제, Corvallis에 적어도 하나의 어드레스를 가지는 모든 사람의 이름을 찾는 이하의 질의를 고려하자.

도 10에 도시된 실행 플랜은 iv_city(언네스팅된 결과에 대한 인덱싱된 뷰) 및 persion, pid의 키에 대한 베이스 테이블 "person"으로의 후방 결합을 모두 이용함으로써 상기 질의에 답할 수 있다.

후방-결합 오퍼레이션(도 10에 도시된 바와 같음)과 조합하여, 크로스 어플라이 언네스트 인덱싱된 뷰 iv_city는 person의 pcol UDT 필드 값의 어드레스 집합에서 개별적인 어드레스 값 내에 포함된 city에 기초하여, "person" 테이블 로우의 고속 관련 검색을 가능하게 한다.

주어진 예의 데이터에 대해, 좌측의 인덱스 스캔은 iv_city의 단지 하나의 로우만(상기 iv_city의 컨텐츠를 예시하는 표 2의 마지막 하나)을 식별할 것이다. iv_city의 이러한 로우는 Bob에 대힌 person의 로우와 결합한다. Bob의 "person" 테이블 로우는 상기 세미-결합 오퍼레이터(semi-join operator)를 전달할 것이다. 도 10에서, "네스트-루프 우측 세미-결합(nest-loop right semi-join)"은 후방-결합 오퍼레이션과 같이 동작한다. 그리고나서, pid 및 pcol.name 필드가 프로젝트되어, 다시 하나의 로우가 된다. 어떠한 중복도 없으므로, 소팅 및 중복 제거가 그 입력 스트림을 변경하지 않는다. 최종 결과는 표 3에 도시되어 있다.

더 구체적으로는, 인덱싱된 뷰로부터 후방-결합에 대해, 인덱싱된 뷰 V가 N개의 베이스 테이블, T1, ..., TN의 함수인 것으로 가정하자. 또한, V는 선택, 프로젝트, 결합, 분류(group-by), 및 집단(aggregation) 오퍼레이션만을 이용하여 구성된다고 가정한다. 각 테이블 T1...TN은 그 테이블에 대해 메타데이터에서 식별된 하나 이상의 키를 가지고 있다. 키는 세트의 값들이 테이블의 로우를 고유하게 식별하도록 하는 테이블의 하나 이상의 칼럼의 세트이다.

T1...TN에 대해 정의된 질의 Q에 매칭하는 로우의 세트는 단지 V 내의 로우만을 이용하여 식별될 수 있다고 가정하자. (Q는 더 큰 질의의 일부일 수 있다. 일반성이 상실되지 않고, Q를 프리-스탠딩(free-standing) 질의로서 간주하라.) Q의 결과의 로우들이 V를 참조함으로써 식별될 수 있지만, 이것은 Q로부터 기인하는 로우가 전적으로 V로부터 구성될 수 있다는 것을 의미하지는 않는다. 그것은, Q의 결과에 나타나는 것이 바람직한 일부 캄럼들이 T1...TN 중 하나에만 나타나는 경우일 수 있다.

인덱싱된 뷰 V로부터 뷰가 정의되는 베이스 테이블 T(T1...TN 중 하나)로의 후방 결합은 T의 임의의 키 상에서 V와 T간의 동일-결합, 및 T의 해당 키로부터 그려지는 V의 필드(들)로 정의된다. 후방 결합이 수행될 수 있는 키는 단일 또는 복수-칼럼 주요 키, 또는 단일 또는 복수-칼럼 후보 키일 수 있으나, 이들로 제한되지 않는다. 키는 인덱스를 가질 수도 또는 그렇지 않을 수도 있다. 키가 인덱스를 가지고 있는 경우, 인덱스는 클러스터링되거나 그렇지 않을 수도 있다. 후방 결합은 여기에서 베이스 테이블의 클러스터링 키에 대해 수행되고 있는 것으로 기재되어 있지만, 본 발명은 임의의 타입의 키에 대해 후방 결합을 수행하는 능력을 포함한다.

후방 결합의 예로서, 이하의 SQL 문장을 이용하여 정의된 테이블을 고려하자.

베이스 테이블 "emp"는 이하와 같이 eno에 대해 순서화된 클러스터링된 액세스 경로를 이용하여 저장될 것으로 정의한다.

eno는 emp의 키이다. 이제, 이하와 같이 정의된 인덱싱된 뷰를 고려하자.

이제, 이하의 질의를 고려하자.

이러한 질의를 해결하기 위해 후방 결합으로 인덱싱된 뷰 "highpaid"를 이용하는 방법의 하나의 예로서, 도 11에 도시된 액세스 플랜(access plan)은 질의에 대한 답변의 예를 제공할 것이다. 도 11에 도시된 바와 같이, 인덱싱된 뷰 "highpaid"로부터 선택된 로우는 후방-결합 오퍼레이션으로서 "네스팅된-루프-결합(nested-loop-join)" 오퍼레이션을 이용하여, 키 eno 상의 베이스 테이블 "emp"에 후방으로 결합된다. 그러므로, 용어 "후방-결합(back-join)"은 인덱싱된 뷰로부터 다시 키 상의 베이스 테이블로의 결합을 기술하는데 이용된다.

임의의 타입의 결합 알고리즘이 후방-결합(예를들면, 네스팅된 루프, 소트-병합, 해시)과 함께 이용될 수 있다고 생각된다.

도 12는 네스팅된 데이터를 가지는 베이스 테이블의 데이터를 질의하는 예시적인 방법의 흐름도이다. 단계 600에서, 질의가 수신된다. 단계 610에서, 베이스 테이블의 데이터에 대한 인덱싱된 뷰가 수신, 검색, 또는 아니면 생성된다. 단계 620에서, 질의 옵티마이저는 질의가 인덱싱된 뷰와 매칭하는 질의 패턴과 매칭하거나 포함하는지 여부를 결정한다. 단계 630에서, 질의 또는 그 일부가 인덱싱된 뷰와 매칭한다면, 질의 옵티마이저는 함수 적용을 수행하는 대신에 매칭하는 인덱싱된 뷰를 인덱스로서 이용하는 플랜을 생성한다. 단계 640에서, 인덱싱된 뷰가 원래 질의에서 요구되는 모든 칼럼을 전달할 수 없는 경우에, 옵티마이저는 원래 베이스 테이블과의 후방-결합을 도입하여, 클러스터링 키를 통해 소실된 칼럼을 획득한다. 이것은 인덱싱된 뷰에 존재하지 않는 베이스 테이블로부터의 필드가 질의 결과에 포함될 수 있도록 허용한다.

단계 650에서, 질의 또는 그 일부가 임의의 인덱싱된 뷰와 매칭하지 않는 경우, 질의 옵티마이저는 데이터에 대해 원래 함수를 적용하는 플랜을 생성한다.

본 발명은 타입 계층에 대해 부분적인 인덱스로서의 인덱싱된 뷰뿐만 아니라, 부분 인덱스의 일반화로서 인덱싱된 뷰를 허용한다. 인덱싱된 뷰에, 인덱싱된 뷰로부터 베이스 테이블로 후방 결합하는 능력을 조합함으로써, 본 발명은 부분 인덱스로서 알려진 기술로의 일반화를 제공한다. 인덱싱된 뷰와 후방-결합 능력을 합하면 부분 인덱스보다 더 강력한 능력 세트를 제공된다.

테이블에서 단지 로우 서브세트의 인덱스를 생성하기 위해, 인덱싱된 뷰 정의(예를 들면, Where 절)에 적절한 조건이 제공된다. 예를 들면, 뷰를 생성하여 person "Fred"의 검색을 가속하기 위해, 이하의 인덱싱된 뷰가 정의된다.

베이스 테이블의 클러스터링 키에 대해 후방-결합을 수행하는 능력, 및 인덱싱된 뷰에 대한 기존의 질의 매칭 능력이 주어지면, 이러한 인덱싱된 뷰는 "Select*from person where pcol.name='Fred' "와 같은 질의에 답하는 것을 도와줄 수 있다. 이러한 질의는 인덱싱된 뷰에서 하나의 로우를 판독하고 이를 다시 person 테이블에 결합함으로써 해결될 수 있다.

또한, 인덱싱된 뷰와 베이스 테이블로의 후방 결합의 능력을 합하면 오브젝트-관계형 DBMS(데이터베이스 관리 시스템)에서 사용자-정의된 타입 세트(또는 UDT 또는 오브젝트로 알려짐)를 인덱싱하는 것이 지원될 수 있다. 타입들이 일반화 계층(타입 계층 또는 IS-A 계층으로도 알려짐)으로 배열되는 경우, 인덱싱된 뷰와 후방 결합 능력의 합을 이용하여 그 타입이 주어진 타입이거나 그 서브타입 중 하나인 테이블에 값들을 인덱싱할 수 있다.

타입에 대해 필터링된 부분 인덱스는 필요하거나 요구되지 않는 서브 타입의 필드에 대해 인덱싱하기 위해, 계산된 칼럼 상의 종래 인덱스가 구현될 수 있다. 계산된 칼럼의 값들은 바람직하게는 인덱싱될 타입을 가지고 있지 않는 타입에 대해 NULL이 될 것이다. 인덱스는 클러스터링되거나 클러스터링되지 않을 수도 있다. 예를 들어, 사람의 급여에 대해 클러스터링된 인덱스를 생성하기 위해, 종업원이 아닌 급여 필드는 NULL이 될 것이다.

주어진 UDT 칼럼에 대해 타입 계층의 서브세트를 인덱싱하기 위해(예를 들면, 그 서브세트의 값들만이 인덱싱되기를 바라는 특정 속성을 가지므로), 뷰 정의의 Where 절에서 IS OF 술어(predicate)를 이용하여 부분 인덱스를 생성하라. 예를 들면, 종업원이 아닌 사람에 대해 인덱스의 레코드를 포함하지 않는 종업원 급여에 대해 인덱스를 생성한다.

이러한 예시적인 인덱싱된 뷰는 비-종업원 급여에 대해 NULL 엔트리를 가지지 않는다. 비-종업원은 뷰의 Where 절의 IS OF 조건에 의해 필터링되어 제거되는 것이 바람직하므로, 인덱싱되지 않는다.

XML 필드의 인덱싱

본 발명의 양태들은 XML 값으로 된 데이터 필드를 인덱싱하는데 이용될 수 있다. 데이터베이스의 테이블에 저장된 관계형 데이터와 대조적으로, XML은 반-구조화된다. 데이터는 사전(a priori) 선언된 스키마에 부착되지 않고 스키마 정보를 표현하는 태그로 주석이 달린다. 종래의 데이터베이스 시스템에서 XML 데이터를 인덱싱하고 처리하기 위해서는, 테이블 포맷으로 분리되어야 한다. 이하의 예는 XML 부분 및 도 4에 도시된 하나의 가능한 대응 테이블 포맷을 도시하고 있다.

XML을 테이블 포맷으로 분리하는 다양한 다른 방법들이 가능하고, 본 발명은 특정된 하나를 이용하는 것으로 제한되지 않는다. 오히려, 예를 들면, XML 부분이 주어지면 테이블-값으로 된 포맷을 출력하는 본원의 XMLTransform으로 지칭되는 임의의 함수가 이용될 수 있다.

함수 XMLTransform은 상기 설명된 바와 같이 테이블-값으로 된 함수이다. 본 발명은 XML 부분에 걸쳐 XMLTransform의 호출 결과를 인덱싱하는 것을 허용한다. 예를 들면, 사용자는 TAG, VALUE, 및 HIERARCHICAL INFORMATION 칼럼 또는 그 조합에 대해 인덱스를 구축하기를 원할 수 있다.

사용자들이 XML 부분을 질의할 수 있는 하나의 가능한 방법은 이하와 같이 기입될 수 있다.

여기에서, '<xml>'은 임의의 주어진 XML 부분을 나타낸다. 질의는 값 'Sam Jones'를 갖는 'name'으로 태그되는 요소에 대한 XML 부분을 검색할 것이다.

뿐만 아니라, XML 부분은 XML 텍스트 스트링으로 주어지는 것 대신에 데이터베이스 테이블에 XML 데이터타입 필드의 형태로 공급될 수 있다. XML 데이터타입 칼럼으로부터 XML을 이용하는 질의에 대한 예는 이하와 같이 기입될 수 있다.

이것은 타입 XML 부분에 관한 테이블 sales에 칼럼 salesperson이 있다, 즉 sales의 모든 로우가 salesperson으로 지칭될 수 있는 XML 부분을 포함하고 있다고 가정한다. 상기 질의는 XML 부분을 질의하는 것과 sales 테이블을 질의하는 것을 조합한다. 이것은 01/28/2004에 거래를 종료한 판매원들의 전화 번호를 리턴시킨다.

복수 칼럼 또는 필드 변환

다른 예시적인 실시예는 복잡한 구조의 복수 칼럼 및/또는 복수 필드의 인덱싱을 허용한다. 통상, 데이터베이스 시스템에서의 인덱싱 구조는 복잡한 구조에서 하나의 칼럼 또는 로케이션으로부터의 데이터를 인덱싱할 수 있다. 예를 들면, 표 2와 관련하여 기재된 예는 네스팅된 집합에서 Address 필드를 인덱싱하는 메커니즘을 기재했다. 본 발명의 양태들은 복잡한 오브젝트 또는 하나의 로우 내의 복수의 필드로부터 도출된 데이터를 인덱싱하는데 이용될 수 있다.

표 5의 인덱싱된 뷰의 예는 사람 및 그 거주 지역의 테이블을 기재하고 있다. 데이터에 걸친 함수 호출은 표 6에 도시된 데이터를 리턴할 수 있다.

표 6은 표 5로부터의 데이터에 대해 다른 종류의 인덱싱된 뷰의 결과를 기재하고 있다. 이러한 예에서, 표 5로부터의 복수의 칼럼들이 인덱싱된 뷰에서 함께 인덱싱된다. 이러한 예가 복수의 칼럼을 이용하지만, UDT 또는 양쪽의 조합과 같은 복잡한 오브젝트로부터 복수의 필드를 이용하는 것도 가능하다. 또한, 이러한 변환은 데이터의 칼럼 또는 필드에 적용된 특별한 로직을 포함할 수 있다. 이러한 예에서, 각 스테이트의 생략은 타겟 변환과 원래의 소스 데이터의 일부이다. 그러나, 각 스테이트의 전체 이름은 함수 호출의 일부로서 생성되어 결과에 삽입된다. 다수의 변환이 가능하고, 하나의 값에 대해 추가 매핑을 도입하는 것에 제한되지 않는다. 가능한 매핑은 칼럼 내의 데이터의 서브-스트링을 취하고, 복수의 칼럼 또는 필드로부터의 데이터를 일부 방식으로 조합하거나, 단일 칼럼 또는 필드로부터의 복수의 워드를 복수의 로우로 분리하는 것을 포함하나, 이들로 제한되지 않는다. 표 6은 또한 단일 필드로부터의 복수의 워드들이 복수의 로우에 리턴되는 예를 포함한다. 표의 추가 칼럼은 후방 결합을 가능하게 하거나 함수 호출의 결과의 고유성을 보장하도록 칼럼을 도입하는 로케이터 칼럼을 포함하는데 이용될 수 있다.

이러한 예시적인 변환은 복잡한 변환의 결과의 인덱싱을 허용한다. 이는 특정 클래스의 질의에 대해 데이터에 대한 더 효율적인 질의를 가능하게 한다. 하나의 그러한 질의는 이하와 같이 기입될 수 있다.

이러한 질의에서, 원하는 결과는 워드 'Lake' 또는 워드 'California'와 일부 연관을 가지는 사람들을 찾아내는 것이다. 이러한 연관은 테이블의 임의의 칼럼에 대한 정확한 칼럼 매치일 수 있고, 또는 테이블의 데이터에 대해 추가적이고, 잠재적인 사용자-정의된 로직의 결과일 수 있다. 이러한 예에서, 'Lake'는 'Sara'를 포함하는 레코드와 연관된 하나의 필드의 제2 워드이고, 한편, 'California'는 'Bob'을 포함하는 레코드와 관련된다. 이러한 로직은 함수 'SOMECOLUMNCONTAINS'에 캡슐화되지만, 이는 임의의 검색 컨텍스트에 이용될 수 있다. 예를 들면, 다른 함수들이 본 발명을 유사한 방식으로 이용할 수 있지만, 동일한 로직이 SQL 함수 'LIKE'를 이용하여 적용될 수 있다.

질의 프로세서는 이러한 함수 호출의 결과에 대해 생성된 인덱싱된 뷰를 이용하여, LIKE 또는 SOMECOLUMNCONTAINS를 포함하는 질의를 효율적으로 해결할 수 있다. 이러한 로직은 바람직하게는 데이터에 대한 이러한 특정 함수 호출의 결과를 포함하는 인덱싱된 뷰를 효율적으로 찾기 위해 매칭 로직을 이용하는 것만이 필요하다.

결론

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

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

본 발명이 다양한 도면의 양호한 실시예와 관련하여 설명되었지만, 다른 유사한 실시예들이 이용되거나 본 발명에서 벗어나지 않고 본 발명의 동일한 기능을 수행하기 위해 기재된 실시예에 변형 및 추가가 가능하다는 것은 자명하다. 예를 들면, 본 발명의 예시적인 실시예가 퍼스널 컴퓨터의 기능을 에뮬레이션하는 디지털 디바이스의 컨텍스트로 기재되어 있지만, 본 기술분야의 숙련자라면, 본 발명이 본 명세서에 기재된 디지털 디바이스에 한정되지 않고, 게임 콘솔, 핸드헬드 컴퓨터, 휴대용 컴퓨터 등과 같은 현재 또는 대두되고 있는 다수의 컴퓨팅 디바이스에 유선 또는 무선에 관계없이 적용될 수 있고, 통신 네트워크를 통해 접속되어 네트워크를 통해 상호작용하는 임의의 개수의 그러한 컴퓨팅 디바이스에 적용될 수 있다는 것을 잘 알고 있을 것이다. 또한, 특히 다수의 무선 네트워킹된 디바이스가 계속해서 증가하고 있으므로, 핸드헬드 디바이스 오퍼레이팅 시스템 및 다른 어플리케이션 특정 오퍼레이팅 시스템을 포함하는 다양한 컴퓨터 플랫폼이 본원에서 고안될 수 있다는 것이 강조되어야 한다. 그러므로, 본 발명은 임의의 하나의 실시예로 제한되지 않고, 첨부된 청구의 범위에 따라 그 범주와 범위가 정해진다.

Claims (33)

1. 베이스 테이블(base table)에 상주하는 데이터를 질의하기 위한 방법으로서,

   질의를 수신하는 단계;

   데이터에 대한 함수 호출을 위한 인덱싱된 뷰(indexed view)를 수신하는 단계 - 상기 함수 호출은 테이블 값으로 된 함수(table-valued function)를 포함함 -;

   상기 인덱싱된 뷰를 인덱스로서 상기 데이터에 대한 상기 함수 호출에 적용하는 단계; 및

   상기 데이터에 대한 상기 함수 호출에 대해 상기 인덱스를 이용하여 질의 결과를 결정하는 단계

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

   상기 질의 결과를 결정하는 단계는 네스팅된 데이터(nested data)에 대해 언네스팅 오퍼레이션(unnesting operation)을 수행하는 단계를 포함하는 방법.
3. 제2항에 있어서,

   상기 언네스팅 오퍼레이션은 크로스 어플라이 언네스트(cross apply unnest) 오퍼레이션인 방법.
4. 제2항에 있어서,

   상기 언네스팅 오퍼레이션을 수행하는 단계는 언네스팅된 결과를 제공하고, 상기 언네스팅된 결과에 대해 뷰를 인덱싱하는 단계를 더 포함하는 방법.
5. 제1항에 있어서,

   상기 인덱싱된 뷰로부터 베이스 테이블로의 후방 결합(back-join)을 제공하는 단계를 더 포함하는 방법.
6. 제5항에 있어서,

   데이터의 논리적 로우 로케이터(logical low locator)로서 기능하는 클러스터링 키(clustering key)를 결정하는 단계를 더 포함하는 방법.
7. 제6항에 있어서,

   상기 클러스터링 키는 고유한 방법.
8. 제6항에 있어서,

   상기 클러스터링 키를 통해 상기 인덱싱된 뷰로부터 상기 베이스 테이블로 후방-결합하는 단계를 더 포함하는 방법.
9. 제5항에 있어서,

   상기 후방 결합은 상기 인덱싱된 뷰에 없는 상기 베이스 테이블로부터의 필드들이 상기 질의 결과에 포함되도록 허용하는 방법.
10. 제1항에 있어서,

    상기 인덱싱된 뷰는 복수의 부분 인덱스(partial index)의 일반화(generalization)인 방법.
11. 제1항에 있어서,

    상기 인덱싱된 뷰는 타입 계층(type hierarchy)에 대한 부분 인덱스인 방법.
12. 제1항에 있어서,

    상기 인덱싱된 뷰를 인덱스로서 상기 데이터에 대한 상기 함수 호출에 적용하기 전에, 상기 인덱싱된 뷰가 질의 패턴에 매칭하는지를 결정하는 단계를 더 포함하는 방법.
13. 제1항에 있어서,

    상기 데이터는 XML 값으로 된 데이터 필드들을 포함하는 방법.
14. 제1항에 있어서,

    상기 데이터는 복합 구조(complex structure)의 복수 칼럼 또는 복수 필드를 포함하는 방법.
15. 데이터 구조를 저장하고 있는 컴퓨터 판독가능한 매체로서,

    오브젝트를 포함하는 제1 데이터 필드; 및

    상기 오브젝트와 연관된 데이터를 포함하는 제2 데이터 필드 - 상기 데이터는 상기 데이터에 대한 함수 호출로부터 도출되고, 상기 함수 호출은 테이블 값으로 된 함수를 포함함 -

    를 포함하는 컴퓨터 판독가능한 매체.
16. 제15항에 있어서,

    상기 데이터는 언네스팅 오퍼레이션으로부터 도출되고, 상기 제1 데이터 필드 및 상기 제2 데이터 필드는 클러스터링 키를 포함하는 컴퓨터 판독가능한 매체.
17. 제16항에 있어서,

    상기 클러스터링 키는 인덱싱된 뷰를 베이스 테이블에 후방 결합할 수 있는 컴퓨터 판독가능한 매체.
18. 제15항에 있어서,

    상기 데이터는 XML 값으로 된 데이터 필드들을 포함하는 컴퓨터 판독가능한 매체.
19. 제15항에 있어서,

    상기 데이터는 복합 구조의 복수 칼럼 또는 복수 필드를 포함하는 컴퓨터 판독가능한 매체.
20. 네스팅된 데이터 집합의 컨텐츠를 인덱싱하는 방법으로서,

    상기 네스팅된 데이터 집합에 언네스팅 오퍼레이션을 수행하는 단계; 및

    상기 언네스팅 오퍼레이션의 결과에 대해 인덱싱된 뷰를 생성하는 단계

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

    상기 언네스팅 오퍼레이션은 크로스 어플라이 언네스트 오퍼레이션(cross apply unnest operation)인 방법.
22. 컴퓨터 시스템에 있어서,

    데이터, 및 상기 데이터에 대한 함수 호출을 위한 인덱싱된 뷰를 포함하는 데이터 스토어 - 상기 함수 호출은 테이블 값으로 된 함수를 포함함 -; 및

    상기 인덱싱된 뷰를 질의하기 위한 하드웨어/소프트웨어 인터페이스 시스템

    을 포함하는 컴퓨터 시스템.
23. 제22항에 있어서,

    상기 데이터는 네스팅된 데이터를 포함하고, 상기 하드웨어/소프트웨어 인터페이스는 상기 네스팅된 데이터에 대해 언네스팅 오퍼레이션을 수행함으로써 질의 결과를 결정하는 컴퓨터 시스템.
24. 제23항에 있어서,

    상기 하드웨어/소프트웨어 인터페이스는 상기 언네스팅 오퍼레이션의 상기 결과에 대해 뷰를 인덱싱하는 컴퓨터 시스템.
25. 제22항에 있어서,

    상기 하드웨어/소프트웨어 인터페이스는 클러스터링 키를 통해 상기 인덱싱된 뷰로부터 베이스 테이블로의 후방-결합을 제공하는 컴퓨터 시스템.
26. 제22항에 있어서,

    상기 데이터는 XML 값으로 된 데이터 필드들을 포함하는 컴퓨터 시스템.
27. 제22항에 있어서,

    상기 데이터는 복합 구조의 복수 칼럼 또는 복수 필드를 포함하는 컴퓨터 시스템.
28. 데이터에 대한 인덱싱된 뷰를 질의할 수 있는 하드웨어/소프트웨어 인터페이스 시스템.
29. 제28항에 있어서,

    상기 하드웨어/소프트웨어 인터페이스는 네스팅된 데이터에 대해 언네스팅 오퍼레이션을 수행함으로써 질의 결과를 결정하도록 되어 있는 하드웨어/소프트웨어 인터페이스 시스템.
30. 제29항에 있어서,

    상기 하드웨어/소프트웨어 인터페이스는 상기 언네스팅 오퍼레이션 결과에 대해 뷰를 인덱싱하는 하드웨어/소프트웨어 인터페이스 시스템.
31. 제28항에 있어서,

    상기 하드웨어/소프트웨어 인터페이스는 클러스터링 키를 통해 상기 인덱싱된 뷰로부터 베이스 테이블로의 후방 결합을 제공하는 하드웨어/소프트웨어 인터페이스 시스템.
32. 제28항에 있어서,

    상기 데이터는 XML 값으로 된 데이터 필드들을 포함하는 하드웨어/소프트웨 어 인터페이스 시스템.
33. 제28항에 있어서,

    상기 데이터는 복합 구조의 복수 칼럼 또는 복수 필드를 포함하는 하드웨어/소프트웨어 인터페이스 시스템.

Images