Indexing - 편집 역사

Pinkgo: /* B+-Tree Extensions */

2025-06-11T05:26:43Z

B+-Tree Extensions

← 이전 판		2025년 6월 11일 (수) 05:26 판
251번째 줄:		251번째 줄:
	* 공간 오버헤드가 커진다. 동일한 검색 키 값을 가진 레코드 수만큼 키 값이 중복 저장되기 때문이다.		* 공간 오버헤드가 커진다. 동일한 검색 키 값을 가진 레코드 수만큼 키 값이 중복 저장되기 때문이다.

	===[[B<sup>+</sup>-Tree Extensions]]===		===[[B+-Tree Extensions\|B<sup>+</sup>-Tree Extensions]]===
	자세한 내용은 [[B<sup>+</sup>-Tree Extensions]] 문서를 참조하십시오.		자세한 내용은 [[B+-Tree Extensions\|B<sup>+</sup>-Tree Extensions]] 문서를 참조하십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* B+-Tree Structure */

2025-06-11T05:25:39Z

B+-Tree Structure

← 이전 판		2025년 6월 11일 (수) 05:25 판
218번째 줄:		218번째 줄:
	# 그리고 해당 leaf 노드와 그 이후의 leaf 노드들을 순차적으로 탐색하며, 검색키 값 <code>C.K<sub>i</sub></code>가 <code>lb ≤ C.K<sub>i</sub> ≤ ub</code>를 만족하는 모든 레코드 포인터를 집합 resultSet에 모은다.		# 그리고 해당 leaf 노드와 그 이후의 leaf 노드들을 순차적으로 탐색하며, 검색키 값 <code>C.K<sub>i</sub></code>가 <code>lb ≤ C.K<sub>i</sub> ≤ ub</code>를 만족하는 모든 레코드 포인터를 집합 resultSet에 모은다.
	# <code>C.K<sub>i</sub> > ub</code>가 되거나 트리에 더 이상 키가 없으면 종료된다.		# <code>C.K<sub>i</sub> > ub</code>가 되거나 트리에 더 이상 키가 없으면 종료된다.
	이제 B<~~sub~~>+</~~sub~~>-트리 인덱스에서의 쿼리 비용을 고려하자. 쿼리를 처리할 때, flow는 트리의 루트에서 리프 노드까지의 경로를 따라 내려간다. 따라서 파일에 N개의 레코드가 있다면, 경로의 길이는 최대 <code>⌈log⌈n/2⌉(N)⌉</code>이다.		이제 B<sup>+</sup>-트리 인덱스에서의 쿼리 비용을 고려하자. 쿼리를 처리할 때, flow는 트리의 루트에서 리프 노드까지의 경로를 따라 내려간다. 따라서 파일에 N개의 레코드가 있다면, 경로의 길이는 최대 <code>⌈log⌈n/2⌉(N)⌉</code>이다.

	실제 구현에서는 이터레이터 인터페이스(iterator interface)을 지원하는데, 해당 인터페이스는 next() 메서드를 지원한다. next() 메서드를 반복 호출하여 연속된 레코드를 가져올 수 있으며, leaf 노드 수준의 항목들을 <code>findRange()</code>와 유사한 방식으로 한 단계씩 탐색하고, 마지막 위치를 기록하여 다음 호출 시 그 다음 항목을 반환한다.		실제 구현에서는 이터레이터 인터페이스(iterator interface)을 지원하는데, 해당 인터페이스는 next() 메서드를 지원한다. next() 메서드를 반복 호출하여 연속된 레코드를 가져올 수 있으며, leaf 노드 수준의 항목들을 <code>findRange()</code>와 유사한 방식으로 한 단계씩 탐색하고, 마지막 위치를 기록하여 다음 호출 시 그 다음 항목을 반환한다.

Pinkgo: /* Nonunique Search Keys */

2025-06-11T05:24:51Z

Nonunique Search Keys

← 이전 판		2025년 6월 11일 (수) 05:24 판
250번째 줄:		250번째 줄:
	* 두 leaf 노드가 같은 검색키 값을 가질 수 있으므로, 내부 노드에서의 분할 처리와 탐색 처리가 훨씬 복잡해진다.		* 두 leaf 노드가 같은 검색키 값을 가질 수 있으므로, 내부 노드에서의 분할 처리와 탐색 처리가 훨씬 복잡해진다.
	* 공간 오버헤드가 커진다. 동일한 검색 키 값을 가진 레코드 수만큼 키 값이 중복 저장되기 때문이다.		* 공간 오버헤드가 커진다. 동일한 검색 키 값을 가진 레코드 수만큼 키 값이 중복 저장되기 때문이다.

			===[[B<sup>+</sup>-Tree Extensions]]===
			자세한 내용은 [[B<sup>+</sup>-Tree Extensions]] 문서를 참조하십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Nonunique Search Keys */

2025-06-11T05:20:02Z

Nonunique Search Keys

← 이전 판		2025년 6월 11일 (수) 05:20 판
242번째 줄:		242번째 줄:
	지금까지 사용한 가정은 검색키가 고유하다는 것이다. 검색키가 고유하지 않은 경우에는 보통 검색키에 기본키 등의 추가 속성을 결합하여 복합 검색 키(composite search key)를 만들고, 이를 모든 레코드에서 고유하도록 한다. 이때 추가 속성은 고유자(uniquifier) 속성이라고 불리며, 레코드 ID, 기본키, 동일한 검색 키 값을 가진 모든 레코드 간에 고유한 값을 가지는 다른 속성이 될 수 있다.		지금까지 사용한 가정은 검색키가 고유하다는 것이다. 검색키가 고유하지 않은 경우에는 보통 검색키에 기본키 등의 추가 속성을 결합하여 복합 검색 키(composite search key)를 만들고, 이를 모든 레코드에서 고유하도록 한다. 이때 추가 속성은 고유자(uniquifier) 속성이라고 불리며, 레코드 ID, 기본키, 동일한 검색 키 값을 가진 모든 레코드 간에 고유한 값을 가지는 다른 속성이 될 수 있다.

	원래의 검색키 속성으로 검색을 수행하기 위해서는 범위 검색(range search)을 이용하거나, 검색키 값만을 매개변수로 받고, 비교 시 고유자 속성은 무시하는 <code>findRange()</code> 함수의 변형을 이용할 수도 있다.		이런 복합 검색키를 이용해 원래의 검색키 속성으로 검색을 수행하기 위해서는 범위 검색(range search)을 이용하거나, 검색키 값만을 매개변수로 받고, 비교 시 고유자 속성은 무시하는 <code>findRange()</code> 함수의 변형을 이용할 수도 있다.

	또한 B<sup>+</sup>-트리 구조를 수정하여 중복 검색 키를 지원하는 것도 가능하다. 이 경우 삽입, 삭제, 탐색 메서드 모두 적절히 수정해야 한다. 한가지 방법은 트리 내의 각 키 값을 단 한번만 저장하고, 해당 검색키 값을 가지는 레코드 포인터 들에 대한 버킷을 유지하는 것이다. 이는 검색키 값을 한 번만 저장하므로 공간 측면에서 효율적이지만, 아래와 같은 단점들이 존재한다:		또한 B<sup>+</sup>-트리 구조를 수정하여 중복 검색 키를 지원하는 것도 가능하다. 이 경우 삽입, 삭제, 탐색 메서드 모두 적절히 수정해야 한다. 한가지 방법은 트리 내의 각 키 값을 단 한번만 저장하고, 해당 검색키 값을 가지는 레코드 포인터 들에 대한 버킷을 유지하는 것이다. 이는 검색키 값을 한 번만 저장하므로 공간 측면에서 효율적이지만, 아래와 같은 단점들이 존재한다:

Pinkgo: /* Nonunique Search Keys */

2025-06-11T05:17:51Z

Nonunique Search Keys

← 이전 판		2025년 6월 11일 (수) 05:17 판
240번째 줄:		240번째 줄:

	===Nonunique Search Keys===		===Nonunique Search Keys===
	지금까지 사용한 가정은 검색키가 고유하다는 것이다. 검색키가 고유하지 않은 경우에는, 검색키에 기본키 등의 추가 속성을 결합하여 복합 검색 키(composite search key)를 만들고, 이를 모든 레코드에서 고유하도록 ~~하는 것이다~~. 이때 추가 속성은 고유자(uniquifier) 속성이라고 불리며, 레코드 ID, 기본키, 동일한 검색 키 값을 가진 모든 레코드 간에 고유한 값을 가지는 다른 속성이 될 수 있다.		지금까지 사용한 가정은 검색키가 고유하다는 것이다. 검색키가 고유하지 않은 경우에는 보통 검색키에 기본키 등의 추가 속성을 결합하여 복합 검색 키(composite search key)를 만들고, 이를 모든 레코드에서 고유하도록 한다. 이때 추가 속성은 고유자(uniquifier) 속성이라고 불리며, 레코드 ID, 기본키, 동일한 검색 키 값을 가진 모든 레코드 간에 고유한 값을 가지는 다른 속성이 될 수 있다.

	원래의 검색키 속성으로 검색을 수행하기 위해서는		원래의 검색키 속성으로 검색을 수행하기 위해서는 범위 검색(range search)을 이용하거나, 검색키 값만을 매개변수로 받고, 비교 시 고유자 속성은 무시하는 <code>findRange()</code> 함수의 변형을 이용할 수도 있다.

			또한 B<sup>+</sup>-트리 구조를 수정하여 중복 검색 키를 지원하는 것도 가능하다. 이 경우 삽입, 삭제, 탐색 메서드 모두 적절히 수정해야 한다. 한가지 방법은 트리 내의 각 키 값을 단 한번만 저장하고, 해당 검색키 값을 가지는 레코드 포인터 들에 대한 버킷을 유지하는 것이다. 이는 검색키 값을 한 번만 저장하므로 공간 측면에서 효율적이지만, 아래와 같은 단점들이 존재한다:
			* 버킷이 리프 노드에 저장된다면, 크기가 가변적인 버킷을 다룰 코드가 필요하고, 버킷이 리프 노드보다 커질 경우의 처리도 추가로 필요하다.
			* 버킷이 별도의 블록에 저장될 경우, 레코드를 가져오기 위해 추가 I/O 연산이 필요할 수 있다.
			또 다른 방법은 각 레코드 마다 검색키 값을 한 번씩 저장하는 것이다. 이 방식은 leaf 노드가 가득 찼을 때 일반적인 분할 방식으로 처리할 수 있다. 하지만 아래와 같은 단점들이 존재한다:
			* 두 leaf 노드가 같은 검색키 값을 가질 수 있으므로, 내부 노드에서의 분할 처리와 탐색 처리가 훨씬 복잡해진다.
			* 공간 오버헤드가 커진다. 동일한 검색 키 값을 가진 레코드 수만큼 키 값이 중복 저장되기 때문이다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Update of B+-Trees */

2025-06-11T05:01:16Z

Update of B+-Trees

← 이전 판		2025년 6월 11일 (수) 05:01 판
238번째 줄:		238번째 줄:
	===[[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]]===		===[[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]]===
	자세한 내용은 [[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.		자세한 내용은 [[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.

			===Nonunique Search Keys===
			지금까지 사용한 가정은 검색키가 고유하다는 것이다. 검색키가 고유하지 않은 경우에는, 검색키에 기본키 등의 추가 속성을 결합하여 복합 검색 키(composite search key)를 만들고, 이를 모든 레코드에서 고유하도록 하는 것이다. 이때 추가 속성은 고유자(uniquifier) 속성이라고 불리며, 레코드 ID, 기본키, 동일한 검색 키 값을 가진 모든 레코드 간에 고유한 값을 가지는 다른 속성이 될 수 있다.

			원래의 검색키 속성으로 검색을 수행하기 위해서는

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Update of B+-Trees */

2025-06-05T05:23:12Z

Update of B+-Trees

← 이전 판		2025년 6월 5일 (목) 05:23 판
236번째 줄:		236번째 줄:
	위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.		위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.

	===[[Update of B-Trees]]===		===[[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]]===
	자세한 내용은 [[Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.		자세한 내용은 [[Update of B+-Trees\|Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Update of B+-Trees */

2025-06-05T05:21:12Z

Update of B+-Trees

← 이전 판		2025년 6월 5일 (목) 05:21 판
236번째 줄:		236번째 줄:
	위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.		위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.

	===[[Update of B~~<sup>+</sup>~~-Trees]]===		===[[Update of B-Trees]]===
	자세한 내용은 [[Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.		자세한 내용은 [[Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* B+-Tree Index Files */

2025-06-05T05:20:47Z

B+-Tree Index Files

← 이전 판		2025년 6월 5일 (목) 05:20 판
235번째 줄:		235번째 줄:

	위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.		위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.

			===[[Update of B<sup>+</sup>-Trees]]===
			자세한 내용은 [[Update of B<sup>+</sup>-Trees]] 문서를 참조하십시오.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* B+-Tree Structure */

2025-06-05T04:12:18Z

B+-Tree Structure

← 이전 판		2025년 6월 5일 (목) 04:12 판
136번째 줄:		136번째 줄:

	Figure 10은 nstructor 파일에 대한 완전한 B<sup>+</sup>-트리를 보여준다(<code>n = 4</code>). 단순화를 위해 null 포인터는 생략하였으며, 화살표가 없는 포인터 필드는 null 값으로 간주한다. Figure 11은 instructor 파일에 대한 또 다른 B<sup>+</sup>-트리를 보여주는데, 이 경우 <code>n = 6</code>이며, 이 트리의 높이는 <code>n = 4</code>인 트리보다 낮다. 위에서 예시로 제시된 트리들은 모두 균형 트리(balanced tree)이며, 이는 root 노드에서 leaf 노드까지의 모든 경로가 동일하다는 것을 의미한다. 이 속성은 B<sup>+</sup>-트리의 필수 요건이며,<ref>B<sup>+</sup>-트리에서의 'B'는 'Balanced'를 의미한다.</ref> 이는 여러 파일 갱신 작업에 대해 우수한 성능을 제공한다.		Figure 10은 nstructor 파일에 대한 완전한 B<sup>+</sup>-트리를 보여준다(<code>n = 4</code>). 단순화를 위해 null 포인터는 생략하였으며, 화살표가 없는 포인터 필드는 null 값으로 간주한다. Figure 11은 instructor 파일에 대한 또 다른 B<sup>+</sup>-트리를 보여주는데, 이 경우 <code>n = 6</code>이며, 이 트리의 높이는 <code>n = 4</code>인 트리보다 낮다. 위에서 예시로 제시된 트리들은 모두 균형 트리(balanced tree)이며, 이는 root 노드에서 leaf 노드까지의 모든 경로가 동일하다는 것을 의미한다. 이 속성은 B<sup>+</sup>-트리의 필수 요건이며,<ref>B<sup>+</sup>-트리에서의 'B'는 'Balanced'를 의미한다.</ref> 이는 여러 파일 갱신 작업에 대해 우수한 성능을 제공한다.

			B+-트리의 각 노드들은 포인터들을 통해 연결되어 있으므로, 실제 메모리 상에서 물리적으로 가까이 위치할 필요는 없다. 즉, 디스크 상에서 반드시 인접한 블록에 저장되지 않아도 된다. 또한, B+-트리의 non-leaf 노드들은 leaf 노드들을 요약하는 희소 인덱스의 계층(hierarchy of sparse indices)를 구성한다. 또한 이와 더불어, root ~ leaf 노드까지의 경로의 길이가 모두 일정하므로, 트리의 높이가 낮다. 이는 각 레벨의 자식 수가 아래와 같이 구성되어 있기 때문이다:

			* root 노드 바로 아래 레벨의 노드 수: 최소 <code>2 × ⌈n/2⌉</code>개의 값
			* 그 다음 레벨: 최소 <code>2 × ⌈n/2⌉ × ⌈n/2⌉</code>개의 값
			* ...: 지수적으로 각 레벨에서의 노드의 개수가 증가

			이에 따라, 검색키 값이 K개 존재한다면, 해당 B<sup>+</sup>-트리의 높이는 <code>⌈log<sub>⌈n/2⌉</sub>(K)⌉</code>를 넘지 않는다. 이를 통해 탐색 작업에 대해 로그 성능을 보장하여, 매우 빠른 탐색을 보장할 수 있다는 장점이 있다. 또한 노드의 삽입 또는 삭제가 일어나더라도, 영향을 받는 부분은 '''작은 지역적인 범위'''에 국한된다. 또한 그 구조 덕분에 인덱스를 '''logarithmic 시간 안에 재구성 가능하다.'''

	일반적으로 검색키는 중복될 수 있다. 중복 검색 키값을 처리하는 한 가지 방법은, 트리 구조를 수정하여 각 검색키를 해당 키를 가진 레코드 수만큼 leaf 노드에 저장하고, 각 복사본이 하나의 레코드를 가리키도록 하는 것이다. 이 경우 <code>K<sub>i</sub> < K<sub>j</sub></code> 조건은 <code>K<sub>i</sub> ≤ K<sub>j</sub></code>로 수정해야 한다. 하지만 이 방식은 내부 노드에도 중복 검색 키 값이 생길 수 있어, 삽입 및 삭제 절차를 더 복잡하고 비용이 많이 들게 만든다.<br>		일반적으로 검색키는 중복될 수 있다. 중복 검색 키값을 처리하는 한 가지 방법은, 트리 구조를 수정하여 각 검색키를 해당 키를 가진 레코드 수만큼 leaf 노드에 저장하고, 각 복사본이 하나의 레코드를 가리키도록 하는 것이다. 이 경우 <code>K<sub>i</sub> < K<sub>j</sub></code> 조건은 <code>K<sub>i</sub> ≤ K<sub>j</sub></code>로 수정해야 한다. 하지만 이 방식은 내부 노드에도 중복 검색 키 값이 생길 수 있어, 삽입 및 삭제 절차를 더 복잡하고 비용이 많이 들게 만든다.<br>
210번째 줄:		218번째 줄:
	# 그리고 해당 leaf 노드와 그 이후의 leaf 노드들을 순차적으로 탐색하며, 검색키 값 <code>C.K<sub>i</sub></code>가 <code>lb ≤ C.K<sub>i</sub> ≤ ub</code>를 만족하는 모든 레코드 포인터를 집합 resultSet에 모은다.		# 그리고 해당 leaf 노드와 그 이후의 leaf 노드들을 순차적으로 탐색하며, 검색키 값 <code>C.K<sub>i</sub></code>가 <code>lb ≤ C.K<sub>i</sub> ≤ ub</code>를 만족하는 모든 레코드 포인터를 집합 resultSet에 모은다.
	# <code>C.K<sub>i</sub> > ub</code>가 되거나 트리에 더 이상 키가 없으면 종료된다.		# <code>C.K<sub>i</sub> > ub</code>가 되거나 트리에 더 이상 키가 없으면 종료된다.
	이제 B<sub>+</sub>-트리 인덱스에서의 쿼리 비용을 고려하자. 쿼리를 처리할 때, flow는 트리의 루트에서 리프 노드까지의 경로를 따라 내려간다. 따라서 파일에 N개의 레코드가 있다면, 경로의 길이는 최대 ⌈log⌈n/2⌉(N)~~⌉이다~~.		이제 B<sub>+</sub>-트리 인덱스에서의 쿼리 비용을 고려하자. 쿼리를 처리할 때, flow는 트리의 루트에서 리프 노드까지의 경로를 따라 내려간다. 따라서 파일에 N개의 레코드가 있다면, 경로의 길이는 최대 <code>⌈log⌈n/2⌉(N)⌉</code>이다.

			실제 구현에서는 이터레이터 인터페이스(iterator interface)을 지원하는데, 해당 인터페이스는 next() 메서드를 지원한다. next() 메서드를 반복 호출하여 연속된 레코드를 가져올 수 있으며, leaf 노드 수준의 항목들을 <code>findRange()</code>와 유사한 방식으로 한 단계씩 탐색하고, 마지막 위치를 기록하여 다음 호출 시 그 다음 항목을 반환한다.

	보통 노드 크기는 디스크 블록 크기와 동일하게 설정되며, 이는 보통 4KB이다. 검색 키의 크기가 12바이트, 디스크 포인터 크기가 8바이트라고 할 때, n은 약 200이다. 검색 키 크기를 32바이트로 보더라도, n은 약 100이다. n = 100일 때, 파일에 검색 키 값이 백만 개 있다면, 조회에는 <code>⌈log50(1,000,000)⌉ = 4</code>개의 노드 접근만 필요하다. 따라서 루트에서 리프까지 경로를 따라가기 위해 디스크에서 최대 4개의 블록만 읽으면 된다. 이때 루트 노드는 자주 접근되므로 보통 버퍼에 저장되어 있어, 실제로는 3개 이하의 블록만 디스크에서 읽으면 된다.		보통 노드 크기는 디스크 블록 크기와 동일하게 설정되며, 이는 보통 4KB이다. 검색 키의 크기가 12바이트, 디스크 포인터 크기가 8바이트라고 할 때, n은 약 200이다. 검색 키 크기를 32바이트로 보더라도, n은 약 100이다. n = 100일 때, 파일에 검색 키 값이 백만 개 있다면, 조회에는 <code>⌈log50(1,000,000)⌉ = 4</code>개의 노드 접근만 필요하다. 따라서 루트에서 리프까지 경로를 따라가기 위해 디스크에서 최대 4개의 블록만 읽으면 된다. 이때 루트 노드는 자주 접근되므로 보통 버퍼에 저장되어 있어, 실제로는 3개 이하의 블록만 디스크에서 읽으면 된다.
218번째 줄:		228번째 줄:
	* 반면 B<sup>+</sup>-트리의 각 노드는 보통 하나의 디스크 블록 크기만큼의 크기를 가지며, 이에 따라 많은 수의 포인터를 가질 수 있어 트리가 두껍고 낮다.		* 반면 B<sup>+</sup>-트리의 각 노드는 보통 하나의 디스크 블록 크기만큼의 크기를 가지며, 이에 따라 많은 수의 포인터를 가질 수 있어 트리가 두껍고 낮다.
	예를 들어, <code>N = 1,000,000</code>일 때, 균형 잡힌 이진 트리는 조회하는 경로 길이가 약 <code>⌈log2(N)⌉ ≈ 20</code>이다. 각 노드가 서로 다른 디스크 블록에 존재한다면, 조회 시 20개의 블록 읽기가 필요하다. 반면, B<sup>+</sup>-트리는 4개만 읽으면 된다.		예를 들어, <code>N = 1,000,000</code>일 때, 균형 잡힌 이진 트리는 조회하는 경로 길이가 약 <code>⌈log2(N)⌉ ≈ 20</code>이다. 각 노드가 서로 다른 디스크 블록에 존재한다면, 조회 시 20개의 블록 읽기가 필요하다. 반면, B<sup>+</sup>-트리는 4개만 읽으면 된다.

			검색키가 고유하지 않은 경우, 후보키를 이용하여 검색키를 고유하게 다룬다고 이전 문단에서 다루었다. 이때 예를 들어 (name, ID)와 같이 구성된 복합 검색키에 대해, name = v인 모든 레코드들을 탐색할 수 있을까? 이는 아래와 같이 findRange(lb, ub)를 호출함으로서 해결할 수 있다.

			* lb = (v, -∞)
			* ub = (v, ∞)

			위의 함수 호출은 <code>name = v</code>를 만족하는 모든 레코드를 반환한다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]