Indexing - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

2026-01-15T12:50:03Z

봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

← 이전 판		2026년 1월 15일 (목) 12:50 판
255번째 줄:		255번째 줄:

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

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]] 문서를 참조하십시오.

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