KR20070053083A - 단편-기반 직렬화를 위한 시스템 및 방법 - Google Patents

Abstract

단편-기반의 직렬화(fragment-based serialization)를 위한 시스템 및 방법은 단편들에 한 개 이상의 객체 멤버들을 배치시킨다. 단편들은 헤더(header)와 유료부하(payload)를 포함할 수 있다. 헤더는, 단편 유형 표시 및 단편 길이 표시와 같은, 단편에 대한 유용한 정보를 제공할 수 있다. 유료부하는 객체의 한 개 이상의 멤버들을 포함할 수 있다. 기본 멤버들(primitive members)은 레코드 포맷 유료부하를 가진 이진 단편(Binary Fragment)에 저장될 수 있다. LOB와 FS 멤버들은 단편의 추가 특성들을 기재하는 값 유형(Value Type) 필드를 가진 단편들에 저장될 수 있다. 집합들은, 집합의 시작을 표시하는 제1 단편, 집합 요소들을 직렬화하는 한 개 이상의 제2 단편들, 및 집합의 끝을 표시하는 종료기 단편(Terminator Fragment)과 같은, 일련의 단편들에 저장될 수 있다. 단편-직렬화된 객체들은 신속한 실체화(instantiation) 및 저비용의 위치파악(location)과 업데이트를 제공하면서 저장 부하(overhead)를 최소화한다.

단편-기반의 직렬화, 레코드 포맷의 유료부하, 이진 단편, 단편 시퀀스, 실체화, 위치파악, 기본 멤버, 네스트된 멤버, 집합 멤버, LOB 멤버, FS 멤버

Description

단편-기반 직렬화를 위한 시스템 및 방법{SYSTEMS AND METHODS FOR FRAGMENT-BASED SERIALIZATION}

<종래 기술의 문헌 정보>

본 출원서는 본 명세서에서 그 전체내용이 참조되는, 2004년 4월 9일에 출원된 미국특허출원 제10/821,687호에 우선권을 청구한다.

<저작권 공고 및 승인>

본 출원서 개시의 일부는 저작권 보호에 해당하는 내용을 포함할 수 있다. 저작권 소유인은, 특허청 특허 파일들이나 레코드들에 나타나는 것과 같이, 누구라도 특허 문서나 특허 개시를 팩스 재생하도록 하지만, 그외의 경우는 모든 저작권을 소유한다. 다음 공고는 이 문서에 적용될 것이다: Copyright

2003, Microsoft Corp.

<기술 분야>

본 발명은 컴퓨팅에 관한 것이고, 더 구체적으로는, 데이타 객체들의 저장 및 전송에 관한 것이다.

직렬화는 저장 매체에 객체 인스턴스의 상태를 저장하는 프로세스로서 정의될 수 있다. 이 프로세스 동안, 객체의 사적 및 공적 필드들과 클래스 이름은 바 이트 스트림으로 변환되어, 데이타 스트림으로 작성된다. 객체가 순차적으로 분해될 때, 원래 객체의 정확한 복제가 생성될 수 있다.

활성화된 컴퓨터 메모리에, 예를 들어, 사람을 설명하는 데이타를 가진 객체와 같은 객체를 고려하자. 사람 객체는, 이름, 주소, 주민번호, 전화번호, 배우자, 키, 및 몸무게와 같은 다수의 서브컴포넌트 멤버들을 가진다. 사람의 이름이 특정 응용 프로그램에 중요할 수 있는 한편, 몸무게와 키는 그렇지 않을 수 있다. 그러므로, 키와 몸무게와 같은 다른 필드들이 다른 데이타를 위한 공간을 만들기 위해 활성화된 메모리로부터 축출되는 한편, 이름은 그것이 수정될 수 있는 활성화된 메모리에 남아있을 것이다. 궁극적으로, 사람 객체가 응용 프로그램에 더 이상 필요하지 않을 수 있고, 그것은 지속적이거나 다른 컴퓨터로 전송될 수 있다. 객체를 지속하거나 전송하기 위해, 객체는 유용하고 수취가능한 방식으로 객체를 포맷하는 것을 참조하여 직렬화되어야 한다.

위의 예에서, 사람 객체와 같은, 객체의 멤버들은 일반적으로 동일 클래스의 모든 객체들에 대해 일정하다. 예를 들어, 각각의 개인 객체는 이름, 주소, 주민번호, 전화번호, 배우자, 몸무게, 및 키 멤버들을 가진다. 정보는 사람마다 다르며, 일부 사람들에 대해서 정보가 없을 수 있지만("널(null)"), 동일 멤버 필드들의 존재는 일반적으로 사람 클래스의 모든 사람 객체들에 대해 존재한다. 그렇게해서, 사람 클래스는 일반 사람 객체로서 고려될 것이다. 사람 객체는 사람 클래스의 한 개의 인스턴스이다. 이 클래스와 인스턴스의 개념은 다수의 프로그래밍 언어들에 존재한다. 관련된 프로그래밍 언어에 무관하게, 직렬화는 통상적으로 클 래스의 인스턴스들에 수행되어, 직렬화된 객체들을 생성한다.

객체들은 다양한 유형들의 데이타를 가진 멤버들을 포함할 수 있다. 멤버들은 기본적(primitive)이거나 복잡할(complex) 수 있다. 기본 멤버들의 예들로는, 문자열인, 사람 객체의 이름 멤버와 같은 "문자열"; 및 정수인, 사람 객체의 주민번호와 같은 "정수"가 있다. 복잡한 멤버들의 예들로는, 두 개 이상의 기본 멤버들 이 경우에서는 두 개 이상의 정수을 포함하는 전화번호 멤버와 같은 "집합(collection)"; 예를 들어, 다른 사람 객체를 참조하는 전화번호들의 집합 또는 배우자 멤버와 같은, 단순한 기본 멤버 이상의 어떤 구조를 가진 멤버인 "네스트(nested)"; 및 가상적 "미국 주소" 유형과 같은, 한 주소 유형의 서브유형일 수 있어서, 미국 지역이나 미국 사서함과 같은 추가 멤버들을 가정적으로 선언하는 "서브유형(subtype)"이 있다. 멤버들은 다수의 상이한 방식들로 기재될 수 있고, 임의의 수의 패턴들에서 서로 관련된다. 그러므로, 사람 객체와 같은 객체들의 직렬화는 객체에 포함될 수 있는 다양한 멤버들 및 이들 멤버들의 관계들을 효과적으로 다루는 것과 관련된다.

객체들의 직렬화는 산업계에서 다수의 문제점들을 야기시킨다. 직렬화된 객체들은 가능한 작은 저장 공간을 소비해야 한다. 그것이 직렬화될 때, 객체의 크기가 크게 증가하면, 객체의 저장 비용이 너무 높을 것이다. 그러므로, 간결한 표현이 직렬화 포맷의 중요한 양태이다.

직렬화된 객체들은 또한 활성화된 메모리에 효과적으로 실체화(instantiation)되어야 한다. 직렬화된 객체의 다양한 멤버들을 발견하고 동화시키는 프로세싱 비용이 높으면, 그것은 값비싼 프로세서 자원을 유출할 것이다. 유사하게, 직렬화는 전체 객체를 실체화할 필요없이 객체의 멤버들을 실체화하고 업데이트를 하도록 해야 한다. 예를 들어, 단지 사람의 주민번호를 읽고 업데이트하기 위해 전체 사람 객체를 실체화하는 것은, 이름, 전화번호, 주소 등의 멤버들이 동작에 관련되지 않을 때에 그러한 멤버들을 저장하는 데에 필요한 활성화 메모리 자원들의 낭비이다.

직렬화 포맷들은 한 객체에 포함될 수 있는 모든 데이타 유형들을 또한 지원해야 한다. 가장 기본적인 직렬화 포맷은 기본 멤버들만을 지원할 것이지만, 더 세분화된 포맷들은 상술된 네스트된 멤버들, 집합 멤버들, 및 서브유형 멤버들과 같은 복잡한 멤버들을 지원해야 한다. 직렬화 포맷은, 대부분 객체들이 이 특징을 가지므로 몇 개의 레벨들의 네스팅과 상속성을 가진 객체들에 대해 최적화되어야 하는 한편, 또한 그것은 직렬화가 넓은 범위의 클래스들에 대해 유연하게 사용될 수 있음을 보장하기 위해 다수 레벨들의 네스팅과 상속성을 지원해야 한다. 직렬화 포맷은 또한 매우 큰 멤버들의 핸들링에 유연 해야 한다. 일부 멤버들은, 예를 들어, 음악 파일, 사진, 또는 영화일 수 있으며, 그런 큰 멤버들은 아래 더 상세히 설명될 직렬화에 문제점을 제기한다.

이전 직렬화 포맷들은 여러 개의 주목할만한 결함들을 가진다. 한 가지 그런 포맷은 XML 직렬화라고 알려졌다. XML 직렬화는 각각의 멤버에 대해 토큰(token)을 제공한다. 토큰은 멤버 -보통 그 토큰 바로 뒤의 멤버- 를 식별하는 메타데이타를 포함한다. 그러므로, XML 직렬화는 다음과 같이 가시화될 수 있 다:

(토큰 1)멤버 1;(토큰 2)멤버 2;(토큰 3)멤버 3; 등.

그런 직렬화 포맷의 문제들은, 첫번째, 장황함(verbosity)이다: 각각의 멤버와의 메타데이타 토큰들의 저장은 대용량의 디스크 공간을 소비한다. 두번째, 원하는 멤버를 찾기 위해, 토큰들이 검색되어야 하므로, 그런 포맷으로 수취가 손상된다. 이 방식으로 직렬화되는 객체를 읽거나 업데이트하는 가장 효과적 방식은 전체 객체를 실체화하는 것이므로, 이것은 높은 활성화된 메모리 비용에 관련될 것이다.

다른 직렬화 포맷은 "저장 엔진 레코드(Storage Engine record)" 포맷 -또한 "SE 레코드(SE Record)" 또는 단순히 "레코드" 포맷으로서 참조됨- 이다. 이것은 통상적인 데이타베이스 시스템 레코드 포맷이다. 이 직렬화 포맷에서, 주어진 클래스의 객체들에 대한 멤버들은 일정하게 포맷된 레코드들에 저장된다. 각각의 멤버를 설명하는 메타데이타를 제공하는 대신, 특정 클래스의 객체들에 대한 모든 레코드들의 내용들을 설명하는 메타데이타가 존재한다. 이것은 도 10에 제공된 바와 같이 가시화될 수 있다.

SE 레코드 직렬화 포맷은 각각의 개별 멤버에 메타데이타를 요구하지는 않으므로, 그것은 더욱 간략한 직렬화 기술이다. 그 대신 그것은, 도 10의 사람 객체들에 대한 메타데이타(Metadata for Person Objects) 표와 같은, 디스크의 멤버들의 레이아웃(layout)을 설명하는 메타데이타로의 액세스를 요구한다. SE 레코드 포맷의 약점은 그것이, 오늘날 객체들과 같이 저장되는 다수의 음악 파일들, 영화 들, 및 이미지들과 같은, 다양한 길이들의 멤버들의 핸들링에 유연하지 않다는 점이다. 더 정확하게는, SE 레코드 직렬화의 유연성은 높은 프로세싱 비용이 든다. 레코드의 다양한 길이의 데이타의 위치들을 식별하기 위해 오프셋(offset) 표가 사용되면, 다양한 길이의 멤버들은 그런 포맷들로 저장될 수 있다. 오프셋 표의 저장의 결과는, 다양한 길이의 멤버가 업데이트될 때마다, 뒤에 오는 모든 다양한 길이 데이타의 위치들은 조정되어야 한다는 점이다. 이것은 배열의 중간에 바이트들을 삽입하는 것과 비교될 수 있다 -삽입 지점의 오른쪽의 모든 것은 삽입되는 새 바이트들을 위해 공간을 만들기 위해 오른쪽으로 쉬프트되어야 함-.

더욱이, 다양한 저장 포맷들은 데이타베이스들의 사용자들이 데이타베이스 내에 객체들을 효과적으로 저장하도록 하기 위해 디자인된다. 이들 저장 포맷들은 더 유연한 직렬화 포맷으로 더 잘 지원될 수 있다. 예를 들어, 본 명세서에 제공된 직렬화 포맷으로부터 구별되어야 한다. 예를 들어, "데이타베이스 저장소의 객체 지속성을 위한 시스템 및 방법(system and method for object persistence in a database store)"의 표제의 미국특허출원 제10/692,225호(관리번호 MSFT 2852/306819.01)는 데이타베이스에 C#과 같은 객체 지향 언어로 작성된 클래스들과 메소드들을 사용자가 '이입(import)'하도록 하는 것에 관한 것이다. 더욱이, 그것은 데이타베이스에 C# 객체들을 사용자가 저장하도록 하고, 객체들에 대해 메소드들을 호출하도록 한다. 그것은 사용자에게 지속성의 복수 특징들을 제공한다. 사용자는 그 자신의 직렬화 포맷을 정의할 수 있거나, CLR(Common Language Runtime) 직렬화(C# 언어 자체에 의해 제공됨)를 사용할 수 있거나, 또는 SQL 서버가 그 자 신의 포맷으로 객체를 저장하게 할 수 있다. MICROSOFT SQL SERVER

가 C# 객체를 실제로 실체화하지 않고 객체의 일부 필드들을 검색수취하거나 업데이트할 수 있으므로, 이들 옵션들, 특히 후자의 것은 수행 이득을 제공한다. 물론, 메소드 호출과 같은 일부 동작들은 여전히 C# 객체의 실체화를 요구한다.

유사한 배경 및 관련된 기술 설명들은 "데이타베이스 외부에 사용자 정의된 유형의 필드의 저장 및 검색수취하는 시스템 및 방법(System and Method for Storing and Retrieving a Field of User Defined Type Outside of a Database Store.)"의 표제의 미국특허출원 제10/692,227호(관리번호 MSFT-2850/306820.1)에서 발견될 수 있다. 본 출원서는, 본 명세서에 기재된 기술들에 따라 직렬화될 수 있는, UDT들의 파일스트림들(filestreams)을 논의한다. 그런 진보된 데이타베이스 기술들은 더욱 유연하고 더 높은 성능의 직렬화 포맷으로부터 이득을 얻을 수 있다. 유사하게, 직렬화된 객체들에 대해 동작들을 수행하는 개선된 기술들은 그런 진보된 데이타베이스 기술들을 지원하는 편이 나을 것이다.

그러므로, 직렬화 포맷들에 관련된 거래들(trade-offs)은 그 포맷의 메타데이타 온디스크(on-disk) 메모리 부하 vs. 멤버의 위치를 파악하는 활성화된 메모리 부하 vs. 멤버의 위치를 파악하는 프로세싱 비용 vs. 업데이트를 수행하는 비용 vs. 큰 필드들의 핸들링에서의 유연성이다. 이들 거래들에서, 직렬화 기술들에 대한 장애물을 없애기 위한 산업계에서의 진행중인 그러므로 미해결인 필요사항이 있다.

단편-기반 직렬화를 위한 방법 및 시스템은 단편들에 한 개 이상의 멤버들을 위치시킨다. 단편들은 헤더 및 유료부하를 포함할 수 있다. 헤더는, 단편 유형의 표시 및 단편 길이의 표시와 같은, 단편에 대한 유용한 정보를 제공할 수 있다. 유료부하는 객체의 한 개 이상의 멤버들을 포함할 수 있다. 다양한 단편 유형들이 객체 멤버들의 저장 및 검색수취에 효율성과 유연성을 위해 제공된다. 기본 멤버들은 레코드 포맷 유료부하를 가진 단편에 저장될 수 있다. 이 구성은 기본 멤버들의 신속한 위치파악 및 업데이트를 하도록 한다. 큰 객체("LOB") 멤버들은 LOB와 FS 멤버들의 위치들에 대한 위치 유형들을 기재하는 필드를 가진 단편들에 저장될 수 있다. 집합들은 일련의 단편들 -집합의 시작을 지시하는 제1 단편, 집합 요소들을 직렬화하는 한 개 이상의 제2 단편들, 및 집합의 끝을 지시하는 종료기 단편- 에 저장될 수 있다. 이들과 다른 단편 유형들은 직렬화 포맷에 추가적 기능을 제공하는 방식으로 단편들을 생성하고, 단편들에 멤버들을 위치시키고, 단편들을 시퀀싱하는 것을 감독하는 규칙들에 따라 구조화될 수 있다.

도 1은 객체 멤버들을 직렬화(serialization)하기 위해 사용될 수 있는 다양한 단편들(fragments)의 개념적 도시이다. 레코드 포맷으로 기본 멤버들을 포함하는 유료부하(payload)를 가진 이진 단편(Binary Fragment), 논-레코드(non-record) 포맷 유료부하를 가진 단편, 및 유료부하를 갖지않은 단편이 도시된다.

도 2는 단편 헤더(header)의 상세한 일람을 가진 단편을 나타낸다. 헤더는 단편 헤더들에서 사용되는 잠재적 필드들의 선택을 나타내고, 다수의 단편 헤더들 은 도시된 필드들 중의 일부를 생략할 수 있다.

도 3은, 본 발명의 다양한 실시예들에 따라, 단편 시퀀스들(sequences)이 설명에서 제공되는 여러 개의 객체 클래스들의 예를 나타낸다.

도 4는 객체에 네스트된(nested) 멤버들이 없을 때 객체의 기본 멤버들에 대한 단편들을 생성하는 단계들을 나타내는 흐름도이다.

도 5는 객체에 네스트된 멤버들이 있을 때 객체의 기본 멤버들에 대한 단편들을 생성하는 단계들을 나타내는 흐름도이다.

도 6은 객체의 집합 멤버들에 대한 단편들을 생성하는 단계들을 나타내는 흐름도이다.

도 7은 객체의 LOB 및 FS 멤버들을 위한 단편들을 생성하는 단계들을 나타내는 흐름도이다.

도 8은 단편들에 다양한 유형들의 멤버들을 가진 전체 객체를 배치하는 프로세스를 위한 단계들을 나타내는 흐름도이다.

도 9는 본 발명의 다양한 실시예들에 따라 객체들이 데이타베이스의 한 개의 열에 저장됨에 따라 직렬화되는 객체들을 도시한다.

도 10은 메타데이타가 전체 레코드들에게 제공되는 종래 기술 레코드 직렬화 포맷을 도시하며, 대응하는 데이타는 메타데이타에 명시된 포맷에 따른다.

도 11a-h는 본 발명의 선호되는 실시예들에 따라 데이타의 직렬화에 사용되는 다양한 단편 유형들을 나타낸다.

도 12는 도 3에 디스플레이된 tPartTimeEmployee 객체에 대한 단편 시퀀스의 최상위 레벨의 도면이다. 이 단편 시퀀스는 네스팅의 각각의 레벨에 대한 추가 단편들을 포함할 수 있다.

특정 세부사항들이 다음 설명 및 도면들에서 기재되어 본 발명의 다양한 실시예들의 철저한 이해를 제공한다. 그러나, 컴퓨팅 기술과 종종 연관되는 특정한 잘 공지된 세부사항들은 본 발명의 다양한 실시예들을 불필요하게 모호하게 하지 않기 위해 다음 개시에 기재되지 않는다. 더욱이, 당업자들이라면 그들이 아래 기재된 세부사항들 중의 한 개 이상이 없이도 본 발명의 다른 실시예들을 실행할 수 있음을 이해할 것이다. 최종적으로, 다양한 방법들이 다음 개시에서 단계들과 시퀀스들을 참조하여 기재되는 한편, 그런 설명은 본 발명의 실시예들의 명백한 구현을 제공하기 위해서이고, 단계들 및 단계들의 시퀀스들은 본 발명을 실행하기 위한 필수사항인 것으로서 받아들여져서는 안된다.

본 발명의 목적은 개선된 객체 직렬화를 위한 방법 및 시스템을 제공하고, 직렬화된 객체들에 대해 동작들을 위한 기술들을 제공하는 것이다. 이 관점에서, 간략한 표현을 제공하는 직렬화가 제공된다. 제공된 포맷으로 직렬화된 객체들은 활성화 메모리로 효과적으로 실체화될 수 있어서, 직렬화된 객체의 다양한 멤버들을 발견하고 동화시키는 프로세싱 비용들을 감소시킬 수 있다. 유사하게, 객체들의 멤버들은 전체 객체를 실체화할 필요없이 실체화되거나 업데이트될 수 있다. 더욱이, "UDT들(User-defined data types)"을 포함하는 넓은 범위의 데이타 유형들을 위한 지원이 제공된다. 직렬화 포맷은 몇 개의 레벨들의 네스팅과 상속성을 가 진 객체들에 대해 최적화될 수 있지만, 또한 다수의 레벨들의 네스팅과 상속성을 지원할 수도 있다. 그것은 매우 큰 멤버들의 핸들링에 유연하다. 본 발명은 한 개의 열에 다양한 유형들의 저장을 위해 적합한 직렬화 포맷을 제공할 수 있다 -예를 들어, "사람" 객체의 서브유형인 "피고용인" 객체의 인스턴스는 단지 "사람" 객체만을 저장하기 위해 제공되는 한 열에 저장될 수 있음-. 최종적으로, 직렬화 포맷은, 또한 효과적 유형 전개(efficient type evolution)라고도 불리우는 유형에 새 멤버들의 효과적인 추가를 허용한다.

본 발명의 다양한 실시예들에 따른 단편-기반 직렬화는 단편-기반 직렬화 그 자체에 유일한 다수의 양태들과 이점들에 추가하여, 배경에서 기재된 바와 같이, XML-스타일 직렬화의 요소들 중의 일부 및, 또한 배경에 기재된 바와 같이, SE 레코드 직렬화의 요소들 중의 일부를 채택하는 혼성(hybrid) 포맷으로서 개념화될 수 있다. 이 점에서, 객체의 멤버들은 단편들에 위치될 수 있다. 단편들은 도 1에 디스플레이된다.

도 1의 참조에서, 단편은 헤더 및, 일부 경우들에서, 유료부하를 포함할 수 있다. 헤더는, 단편 유형의 표시 및 단편 길이의 표시와 같은, 단편에 대한 유용한 정보를 제공할 수 있다. XML 직렬화 컨텍스트로 각각의 멤버에 대해 토큰이 제공되는 것처럼, 새 헤더가 각각의 단편에게 주어지므로, 이 헤더는 XML 직렬화에 의해 제공되는 토큰들과 좀 유사하다. 그러나, XML 토큰들이 각각의 멤버에 대해 주어지는 한편, 도 1의 단편들은 한 개 이상의 멤버들을 포함할 수 있다. 이것은 여러 개의 데이타 멤버들을 포함하는 유료부하를 가진 단편을 나타내는 단편 1에 도시된다. 단편-기반 방법들은, 예를 들어, 단순한 기본 필드들(정수, 문자열 등)을 가진 객체들, 연결된 객체들의 전체 그래프들, 및 집합들을 포함하는 다양한 데이타 구조들을 직렬화하거나 분해시킬 수 있지만, 이에 제한되지는 않는다.

단편 유료부하는 직렬화된 객체의 멤버(들) 및 임의의 다른 데이타를 포함할 수 있다. 이 유료부하는 유료부하에서 멤버들의 신속한 검색수취를 하도록 하는 내부 멤버들에 대한 SE 레코드 포맷-스타일 직렬화를 채택할 수 있다. 그런 레코드 포맷 유료부하는 도 1의 단편 1의 특징이다. 이 관점에서, 단편-기반 직렬화는 SE 레코드 직렬화의 특징들을 가진다. 메타데이타는 유료부하에 포함된 필드들을 설명하는 헤더나 다른 곳에 저장될 수 있다. 그러므로, 전체 객체를 실체화하지 않고 개별 멤버들의 간략한 표현 및 검색수취의 대응하는 이점들을 얻을 수 있다. 유료부하가 레코드 포맷으로 있을 수 있는 한편, 단편 2 및 단편 3에서 도시된 바와 같이, 반드시 그럴 필요는 없음을 주목한다.

단편의 헤더 부분은, 도 2에 도시된 바와 같이, 다양한 필드들을 포함할 수 있다. 도 2는 확장 헤더 섹션을 가진 단편이 도시되고, 다양하고 가능한 필드들이 도시될 수 있다. 도 2에 도시된 다양한 필드들은 각각의 단편에 포함될 필요는 없음을 주목한다. 그 대신, 단편의 유료부하에 대한 유용한 정보를 제공하는 필드들은 헤더에 포함될 수 있다. 도 2의 다양한 필드들은, 단편들의 다양하게 제안된 유형들의 설명과 연결하여, 아래 더 상세히 설명될 것이다.

본 발명의 다양한 실시예들은 객체들의 직렬화에서 추가 용도를 위한 복수 유형들의 단편들을 사용한다. 다양하게 제안된 단편 유형들이 아래 기재된다. 단 편 유형들을 기재하기 전에, 그러나, 상이한 단편 유형들을 사용하는 동기를 고려한다. 한 가지 동기 요소는 한 객체를 구성할 수 있는 다양한 유형들의 멤버들의 더 나은 직렬화를 허용하기 위한 것이다. 객체들은 상이한 유형들의 복수의 멤버들을 빈번히 포함함을 배경 섹션으로부터 상기한다. 이들 멤버들은, 예를 들어, 다음과 같을 것이다:

작은 기본 멤버들. 이들은 정수("int"), 소수, 및 문자열과 같은 기본 유형들의 멤버들이다.

큰 객체("Large Object;LOB") 및 파일스트림("FS")과 같은 큰 기본 멤버들.

집합과 네스트와 같은 복잡한 멤버들.

서브유형 멤버들. 상속성을 지원하는 임의의 클래스는 서브유형의 데이타일 수 있는 상속된 멤버를 포함하는 클래스의 인스턴스들을 가질 것이다.

상술된 것은 잠재적 멤버 유형들의 일부 리스트이고, 모든 멤버 유형들은 본 명세서에 기재된 단편-기반 직렬화 기술들과 사용하기 위한 후보들로서 고려된다.

<단편 유형들>

직렬화되는 객체에 존재할 수 있는 다양한 유형들의 멤버들을 포함하기 위해, 본 발명은 여러 개의 단편 유형들과 사용될 수 있다. 한 개 이상의 단편 유형들은 단지 한 유형의 멤버에 유용할 것인 한편, 다른 단편 유형들은 복수 멤버 유형들에 유용할 것이다.

다양한 단편 유형들은 단편 내용들에 맞추어진 상이한 포맷들을 가질 수 있 다. 다음 논의에서, 단편 유형이 먼저 기재되고, 그 유형에 대한 제안된 단편 포맷의 가시적 묘사가 뒤따른다. 이탤릭체의 단편 속성들은 선택적이고, 유형(Type) 열의 값에 따른다. 본 발명은 아래 기재된 단편 유형들에 제한되지는 않는다. 본 명세서에 제공된 단편들에 추가하여, 새 단편 유형들은 본 명세서에 제공된 단편-기반 직렬화의 일반 원칙들에 따라 사용되기 위해 개발될 수 있다.

이진 단편 - 도 11(a)는 이진 단편의 다양한 잠재적 실시예들을 디스플레이한다. 이 단편은 유형, 길이, 및 유료부하 필드를 포함할 수 있다. 유형 필드는 단지 1 바이트일 수 있거나, 임의의 수의 바이트들일 수 있다. 유형 필드의 추가 바이트들은 직렬화 포맷을 사용할 때 추가 메모리 부하를 요구할 것이다. 그러므로, 헤더 필드들의 바이트들은 절약하여 사용되어야 한다. 이 관점에서, 1-바이트 유형 필드는 단편의 다양한 특성들을 표시하기 위해 사용하는 다수의 비트들을 포함할 수 있다. 1 비트는 단편이 이진 단편임을 표시하기 위해 사용될 수 있다. 다른 비트는 단편에 포함된 멤버(들)의 유형을 표시하기 위해 사용될 수 있다. 예를 들어, 모든 멤버들이 기본 멤버들이면, 1 비트는 그런 정보를 표시하기 위해 설정될 수 있다. 멤버들이 서브유형 멤버들이면, 1 비트는 그것을 표시하기 위해 설정될 수 있다. 이진 단편이 직렬화된 객체의 첫번째, 또는 단일, 단편이면, 유형 필드의 1 비트가 그것을 표시할 것이다. 유형 필드는 또한 단편(들)에 포함된 객체 유형, 및 전체 객체의 단편들의 수와 유형들과 같은 임의의 추가 유용한 정보를 표시할 수 있다.

한 개의 이진 단편으로 표현된 객체들은 "자체-종료" 단편들로서 유형 필드 에 플래그(flag)되어, 직렬화된 객체의 끝에 종료기 단편을 포함할 임의의 필요성을 없앤다. 이 "자체-종료기(self-terminator)" 플래그는 단편의 유형 필드의 자체-종료기 비트의 형태일 수 있다. 그런 자체-종료기 비트는 또한 단편 헤더의 임의의 다른 필드에 또는 단편 유료부하에 위치될 수 있다. 종료기 단편이 직렬화 객체의 끝을 표시하기 위해 생성될 수 있으므로, 복수의 단편들로 표현된 객체들은 자체-종료기 비트를 설정할 필요가 없다.

상술된 바와 같이 길이는 변동될 수 있지만, 길이 필드는 1 바이트가 최적이다. 길이 필드는 유료부하의 길이를 표시하기 위해 사용될 수 있다. 이진 단편의 유료부하는 임의의 데이타를 포함할 수 있다. 선호된 실시예들에서, 유료부하는 객체의 모든 기본 멤버들을 포함한다. 그런 단편들의 유료부하는 거기에 저장된 기본 멤버들이나 다른 멤버들의 효과적 분해와 업데이트를 하도록 하기 위해 SE 레코드일 수 있다.

LOB 단편 - 도 11(b)는 LOB 단편의 다양한 잠재적 실시예들을 디스플레이한다. 이 단편은 헤더에 유형, 값 유형, 및 길이 필드들을 가질 것이고, LOB나 LOB에 대한 위치 정보를 포함하는 유료부하를 가질 수 있다. 단편들의 각각에서 처럼, 유형 필드는 이경우 단편이 LOB 단편임을 표시하는 1 바이트만일 필요가 있다. 값 유형 필드는 LOB 단편의 내용들을 설명하는 추가 수단을 제공할 수 있다. 그런 값 유형 필드는 LOB 속성들에 대한 유형 필드의 비트들을 소모하는 것은 바람직하지 않은 구현들에서 LOB 속성들에 대한 정보를 포함하기 위해 추가될 수 있다. 이 방식으로, 단지 LOB 단편들이 부하(여기서, 단편당 추가적 1 바이트)를 가진다.

값 유형 필드에 저장된 정보는 LOB가 저장된 위치의 유형을 기재할 수 있다. LOB 멤버들의 위치의 추가 기재의 허용은 큰 값들을 핸들링하는 것에 유연성을 제공한다. LOB 데이타(LOB 참조(LOB reference)와 비교하여)가 LOB 단편에 저장될 때, 응용 프로그램(또는 컴퓨터 사용자)은 LOB 인라인(inline) 유형 단편의 생성을 시작할 수 있고, 8 바이트 길이를 사용할 수 있고, LOB 인라인을 배치시킬 수 있다. 부연하면, LOB는 LOB 단편의 유료부하에 배치될 수 있다. 값 유형 필드가 LOB 인라인 유형을 표시하면, 길이 필드는, 예를 들어, 8 바이트일 수 있고, 유료부하는 LOB 값을 포함할 수 있다.

직렬화된 객체에 LOB 인라인을 포함하는 것은 항상 바람직한 것은 아니다. 이것은 LOB가 대량의 공간을 점유할 수 있기 때문이다. 그러므로, 값 유형 필드는 단편의 유료부하가 LOB 위치로의 포인터를 포함함을 의미하는 LOB 포인터 유형을 표시할 수 있다. 이 시나리오에서, 길이 필드는, 예를 들어, 2 바이트이고, 유료부하는 LOB 참조를 포함할 수 있다. 단편 유료부하가 LOB를 포함한다고 가정되는 데이타베이스의 셀로의 LOB 참조를 포함함을 의미할 수 있는 LOB 지연(LOB Delayed) 유형을 값 유형 필드가 또한 표시할 수 있다. 이 다른 시나리오에서, 단편 길이는, 예를 들어, 2 바이트일 수 있고, 유료부하는 셀 참조를 포함할 수 있다. '셀 참조(cell reference)'는 표 식별자, 행 식별자, 및 열 식별자의 결합이다. LOB 단편에 대한 '경로'(아래 기재되는 바와 같이)와 결합될 때, 셀 참조는 실제 LOB 데이타의 위치를 파악하기 위해 충분한 정보를 준다. 임의의 다른 위치 유형 정보는 LOB나 FS 단편의 값 유형 필드에 포함될 수 있다. LOB 및 FS 단편들 에 대한 그런 추가적 위치 유형 필드의 제공은 부하를 낮게 유지하면서 직렬화 포맷에 추가 유연성을 제공한다.

특정 객체가 직렬화에서 특정 클래스를 위해 제공되는 멤버를 갖지 않으면, 본 명세서에서 논의된 단편들 중의 임의의 것은 널(null)일 것임을 주목한다. 단편이 널이면, 이 정보는 단편을 위한 유형 필드의 비트에 설정될 수 있다. 이 관점에서, 길이 필드와 유료부하는 도 11(b)의 LOB 단편으로부터 제거되어 값 유형 필드에 명시된 임의의 위치를 가진 널 LOB 단편을 형성할 수 있다.

FS(File Stream) 단편 - 도 11(c)는 FS 단편을 위한 다양하고 가능한 실시예들을 디스플레이한다. 모든 단편들처럼, FS 단편은 단편 유형 -여기서, FS 단편-을 표시하는 유형 필드를 가질 수 있다. LOB 단편과 같이, FS 단편은 값 유형 필드를 포함할 수 있다. 다시 말하면, 이 필드는 FS에 대한 다양한 위치 유형들을 표시할 수 있다. FS는 객체의 나머지 부분, 또는 인라인 유형(다시 말하면, 이것은 더 긴 길이, 예를 들어, 8 바이트에 상관할 수 있음)과 직렬화될 수 있다. 그것은 단편 유료부하에서 지시되는 위치에 있을 수 있고, FS의 컨텍스트 내에 있는 FS 포인터 유형은, 예를 들어, 2 바이트의 길이 필드, 및 적절한 FS 파일에 대한 GUID(Global Unique Identifier)를 포함하는 유료부하를 표시할 수 있다. 값 유형 필드는 또한, 예를 들어, 2 바이트의 길이, 및 셀 참조를 포함하는 유료부하에 상관할 수 있는 FS 지연 위치 유형을 표시할 수 있다.

종료기 단편 - 도 11(d)는 종료기 단편에 대한 다양하게 가능한 실시예들을 도시한다. 단편-기반 직렬화의 선호된 구현에서, 단지 유형 바이트만이 종료기 단 편에 관련있다. 이것은 종료기 단편의 기능은 직렬화된 객체의 끝을 표시하기 위해, 또는 직렬화된 객체 내의 관련된 단편들의 집합이나 다른 세트의 끝을 표시하기 위해서이기 때문이다. 종료기 단편은, 그것이 종료기 단편이고 추가 정보를 포함할 필요가 없음을 표시하는 유형 필드로 이 기능을 수행할 수 있다. 그러나, 종료기 단편에 일부 추가 정보를 포함하는 것은 유용할 수 있고, 그런 실시예들은 본 명세서에 기재된 본 발명의 범위 내에 확실히 들어 있다.

집합 시작 단편 - 도 11(e)는 집합 시작 단편에 대한 다양하게 가능한 실시예들을 디스플레이한다. 이 단편은, 예를 들어, 2 바이트의 유형 필드와 비트 필드를 포함할 수 있다. 유형 필드는 단편이 집합 시작 단편임을 표시할 수 있다. 비트 필드는 집합 특성들을 표시할 수 있다. 예를 들어, 비트 필드는 임의의 특정 순서로 되어있지 않은 집합에 대응할 수 있는 "비순서화된(unordered)" 집합을 표시할 수 있다. 그것은 또한 집합이 특정 순서로 되어있음을 표시하는 "순서화된(ordered)" 집합을 표시할 수 있다. 집합 시작 필드는 집합 시작을 표시하므로, 집합을 설명할 목적으로만 사용될 때, 이 단편은 길이 필드를 생략할 수 있고, 그렇게 해서 유료부하를 포함할 필요가 없다. 집합 시작 단편에 포함된 유료부하가 있으면, 그 유료부하를 설명하기 위한 길이 필드를 가질 수 있다. 그러나, 본 명세서에 기재된 선호된 실시예들에서, 집합 시작 단편은 집합을 표시하고 설명하기 위해 사용되고, 그것은 그 자체의 유료부하를 갖지 않으며, 그러므로 길이 필드도 가질 필요가 없다. 그렇게, 널 집합 시작 단편은 도 11(e)의 집합 시작 단편과 매우 유사할 것이다. 널 LOB 단편들과 연결하여 상술된 바와 같이, 집합 시작 단편 이 널인 상황에서 단지 한 가지 차이는 유형 필드에 설정된 비트이다.

집합 요소 단편 - 도 11(f)는 집합 요소 단편에 대한 다양하게 가능한 실시예들을 디스플레이한다. 그런 단편의 유형 필드는 그것이 집합 요소 단편임을 표시할 수 있다. 길이 필드는 집합 요소 단편의 유료부하의 길이를 표시할 수 있다. 도 11(f)는 집합 요소를 포함하는 유료부하의 길이를 표시하기에 충분해야 하는 2바이트의 길이 필드 크기의 예를 도시한다.

위치파악기(locator) 필드는 또한 집합 요소 단편들에 포함될 수 있다. LOB와 FS 단편들로부터의 값 유형 필드와 같은, 위치파악기 필드는 집합 요소 단편의 추가 특성들을 표시하기 위해 사용될 수 있다. 예를 들어, 집합 요소 단편은, 이진 단편의 것과 같은, SE 레코드 포맷으로 유료부하를 가질 수 있다. 단편이 그 자체를 종료하는지를 표시하는 비트를 사용하여, 집합 요소 단편이 자체-종료기인지를 유형 필드가 표시할 수 있다. 자체-종료기 비트가 설정되지 않으면, 시스템은 그 단편에 대해 종료기 단편을 예상할 수 있다. 위치파악기 필드는 FS 단편의 GUID와 매우 유사한 집합의 특정 요소를 지칭하기 위해 사용될 수 있다. 집합 요소 단편의 경우, 그러나, 위치파악기 필드는 집합 내에서 유일하지만 범용으로 유일한 필요는 없는 위치를 표시한다.

위치파악기 필드에 대해, 집합 요소의 위치파악기 필드의 일부 예측을 허용하는 것이 또한 선호될 수 있다. 집합 시작 단편의 비트 필드의 1비트는 위치파악기 필드를 가진 다가오는 집합 요소 단편을 지시하기 위해 설정될 수 있다. 그런 설정에서, 시스템은 위치파악기 필드가 집합 요소 단편에 존재함을 유도하기 위해 설정될 수 있다.

널 집합 요소 단편 - 도 11(h)는 널 집합 요소 단편에 대한 다양하고 가능한 실시예들을 디스플레이한다. 집합 요소 단편들에 대한 널 표현은 단편이 널 집합 요소 단편임을 표시하는 유형 필드를 포함할 수 있다. 널 집합 요소 단편의 존재가 특정하게 직렬화된 객체가 그런 데이타를 포함하기 위해 다르게 디자인된 클래스의 특정 양태에 따른 데이타를 갖지 않음을 지시하므로, 그들은 또한 위치파악기 필드를 포함할 수 있지만, 길이나 유료부하 필드들을 포함할 필요는 없다. 다시 말하면, 다른 멤버 정보나 아무런 멤버 정보가 유료부하에 포함되지 않을 때, 길이 필드가 유료부하의 길이를 기재할 필요가 없을 것이다.

널 단편 - 도 11(g)는 널 단편에 대한 다양하고 가능한 실시예들을 디스플레이한다. 종료기 단편과 같은, 널 단편은 단독 유형 필드에 의해 표현될 수 있다. 다시 말하면, 이것은 실행이 비집합(non-collection) 요소 널 단편들의 표현에 제한될 수 있다는 것이다. 집합 요소 널 단편들의 설명에 대해 아래를 참조한다.

주석 및 메타데이타 단편들 -상술된 다른 단편들에 추가하여, 메타데이타와 주석 단편들은 직렬화된 개체의 수신기에 한 개 이상의 단편들을 기재하기 위해 사용될 수 있다. 그런 단편들은 그들이 객체를 분해하기 위해 불필요할 수 있지만 다양한 상황들에서 유용하다. 예를 들어, 주석 단편은 클라이언트가 특정 멤버나 객체에 대한 정보를 검사하도록 하거나, 직렬화된 객체에 대한 주석이나 정보를 삽입하도록 할 수 있다.

결론적으로, 상술된 다양한 단편 유형들의 설명들을 참조하여, 효과적 직렬 화 포맷에 의해 얻을 수 있는 이점들 중의 하나는 표현 부하의 감소이다. 표현 부하는 객체가 효과적으로 검색수취되도록 하기 위해 객체에 저장된 추가 정보의 양을 참조한다. 단편-기반 직렬화 기술들은 표현 부하를 포함하지만, 부하는 포맷의 대응하는 유연성과 기능성에 대해 최소화된다.

단편 헤더의 제1 필드는 유형 필드이다. 선호되는 실시예들에서, 유형 필드는 1 바이트를 소비한다. 이것은 연관된 부하를 최소화한다. 추가로, 집합 요소 단편과 연관된 위치파악기 필드는 부하가 된다. 대부분 소형의 비순서화된 집합들은 4 바이트 이하를 소비하는 위치파악기 필드에 적절히 표현될 수 있다. 더 큰, 순서화된 집합들은 4 바이트 이상을 소비할 수 있지만, 그러나, 이 경우 위치파악기 필드는 더 많은 표현 부하를 요구할 수 있는 다양한 이진("variable binary;varbinary") 필드로 교체될 수 있을 것이다. 위치파악기 필드에 의해 사용되는 부하의 정확한 양은 구현 세부사항으로 고려되고, 표현 부하를 감소시키기 위한 동기를 이해할 당업자들의 판단에 맏겨지지만, 또한 집합들의 유연한 직렬화를 하도록 한다. 최종적으로, 여러 개의 다른 단편 유형들(위를 참조)과 연관 길이 필드들은 표현 부하이다. 상술된 바와 같이, 선호된 실시예들에서 길이 필드는, 단편 유형에 따라, 2 바이트 또는 8 바이트 길이일 수 있다. 본 발명은 그런 필드들에 대한 정확한 수의 바이트들에 제한되지 않고, 본 명세서에서 기재된 파라미터들은, 본 발명 자체에 대한 하드(hard)하고 신속한 요구사항들이 아닌, 경험있는 실행자로부터의 유용한 조언들로 고려되어야 한다.

<단편에 멤버를 배치시키는 규칙들>

위에 설명된 바와 같이, 다양한 단편 유형들은 다양한 단편 멤버들을 위해 쓸 수 있다. 객체를 직렬화하기 위해, 특정 멤버를 위해 어느 단편 유형을 사용할 지에 대해 결정이 되어져야 한다. 예를 들어, 기본, 네스트, 집합, 및 서브유형 멤버들을 포함하는 객체는 규칙들의 세트에 따라 단편들로 분해될 수 있다. 본 발명이 단편 유형들과 멤버 유형들의 특정 상관 관계에 제한되지 않는 한편, 유용한 규칙들의 세트가 개발되고, 이 섹션에서 설명된다. 설명의 명료성을 위해서 규칙들은, 그들이 특정 순서로 수행되어야 함을 지시하기 위한 것이 아님을 주목한다. 실행에서, 아래 규칙들에 대응하는 동작들은, 객체의 멤버들을 통해 프로세서의 단계들로서 수행되는 단편들의 생성, 배치(population), 및 시퀀싱(sequencing)으로, 동시에 수행될 수 있다. 객체의 직렬화로의 이들 규칙들의 적용의 예에 대해서는 도 3 및 아래 대응하는 텍스트를 참조한다. 규칙들은 다음과 같다.

단편들을 생성한다. 본 발명의 실시예들은 유형-기반 컨테이너(container) 관련 단편 생성에 관여하는 것으로 말해질 수 있다. 부연하면, 다음의 각각에 대해 단편이 있을 수 있다:

클래스에서 네스팅의 각 레벨. 그 레벨이 널일지라도.

각 집합. 그 집합이 널일지라도.

집합의 각 요소.

각 서브유형.

각 LOB 및 FS 속성. 그것이 널일지라도. LOB 값들이 인라인 저장될 수 있는 한편, FS 값들은 아웃오브라인(out-of-line) 저장되어야 한다.

추가 단편들이 특정 클래스의 필요에 적절하기 위해 생성될 수 있다. 유사하게, 위의 단편들은 일부 클래스들의 직렬화를 위해 요구되지 않을 수 있다.

일반적으로, 객체는 톱-투-다운(top-to-down) 기술을 사용하여 단편-기반 직렬화 단편으로 변환될 수 있다. 첫번째, 객체의 임의의 기본 유형 멤버들은 직렬화되고, 서브유형들이 뒤따를 수 있다. 각각의 네스팅 레벨에서, 스캔은 포함된 멤버들로 만들어져 임의의 네스트된 유형, 서브유형, 또는 LOB/FS 유형 멤버들이 존재하는지를 판정할 수 있다.

기본 멤버들을 위한 단편 생성. 일부 또는 전체 기본 멤버들은 한 개 이상의 이진 단편들에 위치될 수 있다. 선호되는 실시예는 네스트된 멤버들을 가진 객체들과는 다르게 네스트된 멤버들을 갖지 않은 객체들을 핸들링한다. 이들 2 개의 시나리오들은 도 4와 도 5에 도시된다. 양쪽 상황들에서, 네스트되지 않은 기본 멤버들은 한 개의 이진 단편 내에 배치될 수 있고, 거기에서 SE 레코드 포맷을 사용하여 직렬화될 수 있다. 네스트된 멤버들이 없는 객체들에 대해, 이진 단편이 생성될 수 있고, 네스트된 멤버들이 없음의 지시는 단편의 유형 필드에 위치될 수 있다. 다양한 실시예들에서, 네스트된 멤버들을 포함하는 객체들과 네스트된 멤버들을 포함하지 않은 객체들 간의 실제 차이는 네스트된 멤버들을 갖는 객체들은 복수 단편들로 직렬화될 수 있는 한편, 네스트된 멤버들을 갖지 않은 객체들은 단일 이진 단편으로 직렬화될 수 있다는 점이다. 그러므로, 네스트된 멤버들이 없으면, 자체 종료기 비트는 이진 단편의 필드에 설정될 수 있다. 이진 단편의 길이 필드는 결합된 기본 멤버들의 길이에 대응하기 위해 설정될 수 있다. 그 다음, 단편은 방출될 수 있다.

도 5의 참조에서, 네스트된 단편들이 존재하면, 이진 단편에 대한 네스트되지 않는 멤버들을 위한 프로세스는 조금 변경되어 네스트된 멤버들이 재귀적으로 직렬화되도록 할 수 있다. 이 상황에서, 자체-종료기 비트는 설정될 필요가 없다. 이진 단편이 방출된 후, 네스트된 유형 멤버들은 그들 자신의 단편들로 재귀적으로 프로세스될 수 있다. 그런 재귀로부터 귀환하면, 종료기 단편이 생성될 수 있다. 그 다음, 종료기 단편이 또한 방출될 것이다.

집합을 위한 단편 생성. 집합 단편들을 생성하는 프로세스의 흐름도는 도 6에 제공된다. 집합 멤버가 대면될 때, 집합 시작 단편이 생성될 수 있다. 집합이 순서화되지 않으면, 비트 필드의 비트는 "비순서화됨"으로 설정될 수 있다. 그 다음, 집합의 각 요소는, 아래 기재된 바와 같이, 집합 요소 단편들을 생성하여 재귀적으로 직렬화될 수 있다. 모든 요소들이 직렬화된 후, 종료기 단편은 집합의 끝을 표시하기 위해 생성될 수 있다.

집합 요소는 한 개 이상의 단편들로 직렬화될 수 있다. 집합 요소가 한 개 이상의 단편들을 사용하여 표현되면, 표현은 그 자신의 종료기 단편을 가질 것이다. 집합 요소의 제1 단편은 위치파악기 필드를 포함할 수 있다. 그런 필드의 한 가지 목적은 집합을 직렬화할 때 프로세스되는 다수의 요소들을 추적하는 것일 수 있다. 직렬화를 위한 현재 요소를 적절히 지시하기 위해 위치파악기 필드의 카운터를 증가시켜, 직렬화 프로세스는 집합의 다음 요소를 직렬화하는 적절한 위치에 귀환할 수 있다.

LOB 및 FS 단편들의 생성. LOB와 FS 멤버들을 위한 단편들의 생성을 도시하는 흐름도가 도 7에 제공된다. 다양한 단편 유형들의 설명에서 지시된 바와 같이, LOB와 FS 단편들 모두는 대응하는 유료부하에 대한 한 개 이상의 위치 유형을 표시하기 위해 구성될 수 있다. 이 표시는 값 유형 필드에 만들어질 수 있다. 예를 들어, 값 유형 필드는 포인터, 인라인, 또는 지연 위치 유형들을 포함하는 것으로서 유료부하를 기재할 수 있다. LOB와 FS 단편들의 생성에서, 적절한 값 유형이 한 멤버로부터 결정될 수 있다. 예를 들어, LOB가 객체에 직렬화되면 -즉, 단편에 인라인 저장됨-, LOB 인라인에 대한 값 유형은 선택될 수 있고, LOB는 대응하여 직렬화될 수 있다. 그 대신에 LOB가 직렬화된 객체가 아닌 데이타베이스 셀에 저장되면, LOB 참조는 객체에 직렬화될 수 있고, 적절한 위치 유형이 값 유형 필드에 저장될 수 있다. 그 다음, 단편이 방출될 수 있다.

서브유형 단편의 생성. 서브유형 단편들은 임의의 다른 기본이 아닌 멤버에 대한 단편들과 동일한 방식으로 생성될 수 있다. 부연하면, 서브유형이 집합 멤버를 포함하면, 임의의 집합 요소 단편들과 종료기 단편과 함께 집합 시작 단편은 서브유형 멤버의 직렬화의 끝을 표시하기 위해 생성될 수 있다. 서브유형 멤버가 네스트된 LOB 멤버이면, LOB 단편은 서브유형 멤버를 포함하기 위해 생성될 수 있다. 이진 단편이 기본 유형에 대해 생성되는 유사한 방식으로, 정수, 소수 등과 같은 모든 작은 기본 멤버들을 포함하는 서브유형에 대해 이진 단편이 생성될 수 있다.

다른 단편들의 생성. 본 명세서에 기재된 기술들은 특정 객체나 객체들의 클래스의 직렬화를 위해 원해지거나 요구될 수 있는 임의의 다른 단편들의 생성으 로 확장될 수 있다.

단편들을 배치시킨다. 단편들이 실제로 생성되고 동시에 배치될 수 있는 한편, 본 발명의 이 양태를 설명할 목적으로 단편들이 배치되는 방법에 대한 전체 계획을 포함하는 것은 유용할 것이다. 이 전체 계획은 도 8에 제공된다. 다양한 단편 유형들로 멤버들의 배치에서, 다음 제안들이 관찰될 수 있다:

LOB 멤버들을 제외한, 모든 기본 멤버들은 이진 단편에 저장될 수 있다. 이 단편의 헤더는 전체 객체에 대한 유형 식별자를 포함할 수 있다. 이 단편의 유료부하는 저장 엔진 레코드를 포함할 수 있다. 단편이 단지 기본 속성들만을 포함하면 단편이 그 자신을 종료한다고 말해진다.

각각의 LOB 멤버는 LOB 단편에 저장될 수 있다.

집합 시작 단편은 각각의 집합 멤버에 대해 생성될 수 있다. 집합 멤버가 비어있지 않으면, 집합 시작 단편은 한 개 이상의 집합 요소 단편들을 참조할 수 있다.

집합 요소 단편은 집합 멤버의 다양한 요소들에 대해 제공된다. 이 단편은 위치파악기를 가진 이진 단편일 수 있다. 위치파악기는 집합 요소가 지정될 수 있는 레이블이다.

종료기 단편은 한 개 이상의 단편들로 분해되는 각각의 집합 멤버에 대해 생성될 수 있다. 종료기 단편은 집합 멤버의 끝을 표시한다.

네스트된 단편들을 가진 단편은 그 자신을 종료하지 않는다. 그 대신, 그것은 단편 내에 네스트된 모든 단편들 후에 나타나는 종료기 단편을 가진다.

종료기 단편은 한 개 이상의 단편들로 분해되는 각각의 객체에 대해 생성될 수 있다. 종료기 단편은 직렬화된 객체의 끝을 표시할 수 있다.

네스트된 객체는 재귀적으로 위와 동일한 규칙들을 따를 수 있다.

직렬화의 목적으로, 서브유형들은 네스트된 객체들로서 다루어질 수 있다.

단편들의 시퀀스. 단편들은 임의의 특정 클래스에 대해 직렬화를 만드는 시퀀스에 저장된다. 객체들의 클래스가 단지 기본 멤버들만을 포함하면, 객체들은 자체-종료 단일 단편에 직렬화될 수 있다. 복잡한 멤버들 또는 다른 기본 멤버들을 가진 클래스들은 한 개 이상의 단편들로 직렬화될 수 있다. 클래스에 대한 직렬화가 한 개 이상의 단편들을 포함하면, 한 개 이상의 종료기 단편들이 또한 생성될 수 있다. 시작 단편으로부터 최종 종료기 단편까지 단편들의 세트는, 그 용어가 본 설명에서 사용되는 것처럼, 단편들의 시퀀스를 포함한다.

한 인스턴스에서 서브유형들에 대응하는 단편들은 기본 유형에 대한 단편 아래에 네스트될 수 있다. 도 3으로부터의 tPerson, tEmployee, 및 tPartTimeEmployee 예를 사용하고, 우선은 각 레벨에 이진 단편들에 의해 기재된 기본 속성들만이 존재함을 가정하여, tPartTimeEmployee의 인스턴스는 도 12에 의해 제공된 도면에 가시적으로 도시될 수 있다. 도 12의 tEmployee 및 tPartTimeEmployee에 대한 단편들은 네스팅과 동일한 레벨에 있을 수 있음을 주목한다.

직렬화의 예

다수의 잠재적 멤버 유형들, 다수의 단편 유형들, 및 단편들에 멤버들을 배치하는 규칙들의 세트의 예를 기재하였으므로, 본 명세서에 기재된 직렬화 포맷의 실시예를 사용한 직렬화의 예는 유익할 것이다. 이 관점에서, 도 3은 여러 개의 샘플 스키마를 제공한다. 각각의 스키마는, 각각이 한 개 이상의 다양한 유형들의 멤버들을 가진, 객체들의 클래스를 나타낸다. 이 논의의 목적으로, 도 3은, 각각의 객체가 이름 문자열(기본 멤버), 나이 정수(또한 기본 멤버), 및 위치 집합(이것은 네스트된 복잡한 멤버임)을 가진, "사람" 객체들의 클래스를 제공한다. 도 3은 또한 "주소" 객체들을 정의하는 클래스를 제공하고, 각각의 그런 객체는 다음 3 개의 기본 멤버들을 가진다: 거리, 도시, 및 우편번호. 도 3은 사람 클래스를 상속하고, 그러므로 사람 클래스의 멤버들을 포함하고, 또한 3 개의 기본 멤버들 -피고용인 번호, 부서, 및 사진(이미지는 LOB 멤버임)- 을 포함하는 피고용인 객체들의 클래스를 제공한다. 비상근(parttime) 피고용인 클래스는 피고용인 클래스를 상속하고, 그러므로, 한 개의 기본 멤버인 주당 시간 수에 추가하여, 피고용인 클래스의 모든 멤버들(사람 클래스로부터 상속된 것들을 포함함)을 포함한다.

도 3의 참조에서, 스키마들의 인스턴스가 위에 제공된 단편들과 규칙들을 사용하여 직렬화되는 방법을 고려한다. 예를 들어, 비어 있지 않은 주소들의 집합을 가진 tPerson의 인스턴스는 다음 순서로 다음 단편들을 가질 수 있다:

m_name 및 m_age를 포함하는 이진 단편.

집합 시작 단편

각 집합 요소에 대해:

m_street, m_city, m_zip을 가진 집합 요소 단편.

집합을 종료하는 종료기 단편.

tPerson의 단편들을 종료하는 종료기 단편.

비어있지 않은 주소들의 집합을 가진 tEmployee의 인스턴스는 다음 순서로 다음 단편들을 가질 수 있다:

m_name과 m_age를 포함하는 이진 단편.

집합 시작 단편.

각 집합 요소에 대해:

m_street, m_city, m_zip를 가진 집합 요소.

집합을 종료하는 종료기 단편.

m_empNo 및 m_dept를 포함하는 서브유형 단편.

m_image를 포함하는 LOB 단편.

tEmployee의 단편들을 종료하는 종료기 단편.

tPerson의 단편들을 종료하는 종료기 단편.

위의 단편 시퀀스들의 예의 참조에서, 저장 엔진 레코드 구성/분해 코드의 재사용을 지원하는 목적으로, 한 개 이상의 단편들에서 레코드 포맷을 사용하는 이들 실시예들에서 원해지는 것처럼, 본 명세서에 기재된 단편-기반 직렬화 기술들과의 사용을 위해 클래스의 레벨은 7 킬로바이트(7Kbytes) 크기를 초과하지 못할 것임을 요구하는 것이 선호됨을 주목한다. 위에 주어진 예에서, tPerson(연관된 주 소들의 집합을 제외함)은 7 킬로바이트 이하의 크기이어야 한다. 유사하게, 각 tAddress는 7K이하이어야 한다. 본 발명을 실행하는 최상의 모드를 지시하기 위한 규정 요구사항들에 따르기 위해 이 제한사항이 개시되는 한편, 레벨이 7K를 초과하는 것을 허용하는 것은, 본 발명의 덜 바람직한 구현이지만, 가능한 것으로 고려됨을 주목한다. 이 제한사항은 실행 시간에 직렬화 라이브러리("SL")에 의해 강제될 수 있다. 이해될 것처럼, 직렬화는 다양한 단편들을 인식하고 파싱(parsing)하는 책임이 있다.

위의 예에서, 한 개 이상의 단편들에 멤버들을 배치하여, 멤버의 위치를 파악하는 작업은 멤버가 배치된 단편(들)의 위치를 파악하는 것과 관련있음을 주목한다. 한 개 이상의 그런 단편들이 존재하면, 제1 단편의 위치가 먼저 파악될 수 있다. 이 관점에서, 직렬화의 제1 단편에 관련된 단편의 위치가 메타데이타로부터 결정될 수 있다. 이 기술이 단편들의 직접 액세스를 제공하지 않는 한편, 각 멤버에 대해 토큰들을 비교하여 연관된 멤버가 클래스의 어느 양태를 나타내는지를 식별하는 작업은 제거됨을 주목한다. 그 대신, 스캔되었을 때, 직렬화 메타데이타는 프로세서를 적절한 단편으로 신속히 지정할 수 있다.

위의 직렬화의 예에서 도시된 바와 같이 본 발명의 다른 이점은 객체의 직렬화는 한 번의 패스(pass)에 성취될 수 있다는 점이다. 직렬화 프로세스는, 기본 유형으로부터 서브유형으로, 포함하는 유형으로부터 네스트된 유형으로, 톱-다운(top-down) 방식으로 진행될 것이다. 네스팅의 각 레벨에서, 직렬화 프로세스는 한 개 이상의 단편들을 생성할 수 있다. 그런 직렬화는 이전에 생성된 단편을 업 데이트하도록, 원하면 그것이 그렇게 설정될 수 있지만, 요구되지 않는다.

본 명세서에 기재된 직렬화 포맷은 고정된, 다양한 길이의, 비트 유형의 기본 멤버들; 다른 객체들 내에 네스트된 객체들; 상속성; 인라인과 아웃오브라인 LOB들(파일 스트림들을 포함함); 순서화된 집합들(위치파악기 기능을 통해, 적절한 순서로 집합 요소들의 직렬화를 제공함); 비순서화된 집합들; 및 널 값들을 지원하기 위해 설정될 수 있음을 알게 될 것이다. 그것은 또한 구성할 수 있는 직렬화들을 지원할 것이다. 이 관점에서, 네스트된 객체는 객체가 직렬화되는 단편 컨테이너의 추적이 없이 -즉, 그것의 컨테이너에 대응하는 아무런 상태가 없이-, 기존 직렬화로부터 추출될 수 있다. 본 발명의 실시예들의 이 특성은 전체 네스트된 객체들의 삽입 및 업데이트를 허용한다.

또한, 위의 직렬화 예로부터, 제안된 직렬화 포맷은 임의의 다른 기존 데이타를 업데이트하지 않고 클래스에 멤버들의 추가를 지원함을 주목한다. 클래스로의 필드들의 추가는, 스키마들이 빈번히 필드들을 추가하여 업데이트되는, XML 스키마들의 사용에서 매우 일반적이다. 이 관점에서, 임의의 유형의 단편은 새 멤버들(기본 객체, 집합 객체, 또는 네스트된 객체)을, 그들이 널 디폴트 값을 가지며 기존 유형의 끝에 추가되는 한, 추가하기 위해 변경될 수 있다. 또한, 제안된 단편-기반 포맷으로 저장된 객체들은 데이타베이스의 한 열에 "바이트 백(bag of bytes)"으로서 저장될 수 있고 임의의 크기일 수 있으므로, 객체로의 큰 멤버들의 추가는 레코드 포맷 직렬화처럼 염려할 필요가 없다.

위의 직렬화의 예에서 구현된 바와 같이 직렬화 포맷의 또 다른 이점은 단편 의 신원이 단편에 저장될 필요가 없다는 점이다. 그 대신, 단편으로의 경로는 단편 신원을 알아내기 위해 사용될 수 있다. 경로는 동작되는 임의의 주어진 객체의 유형 메타데이타로부터 결정될 수 있다. 경로는 직렬화의 특정 단편을 식별한다. 경로는, 예를 들어, 각 네스팅 레벨과 서브유형 레벨에서 단편을 식별하는 각 단편에 숫자들의 세트일 수 있다. 객체의 필드들이 미리 결정된 단편에 있으므로, 그들은 경로를 사용하여 위치가 파악될 수 있다. 일면으로는, 경로들은 단편들에 대한 주소들과 같다. 경로는 단편과 함께 저장될 수 있거나, 제1 직렬화 단편으로부터 내비게이트하여 계산될 수 있다. 유형들의 임베딩과 네스팅을 지원하기 위해, 경로는 네스팅 레벨들과 서브유형 레벨들을 설명할 수 있다.

단편-기반 직렬화 포맷은 또한 객체를 실체화하지 않고 멤버들로의 액세스를 지원하도록 한다. 위에 설명된 바와 같이, 단편 식별자로서 경로를 사용하여, 멤버 위치파악 프로세스나 내비게이터는 임의의 원하는 단편으로 내비게이트할 수 있다. 일단 한 단편에 위치되면, 그런 프로세스는 그 단편 자체로, 또는 위치된 단편으로부터 시작된 단편들의 전체 시퀀스로의 액세스를 허용할 수 있다. 각 단편으로의 맵(map)의 형태로 직렬화의 디렉토리를 제공하여, 단편의 위치파악은 더욱 빨리 성취될 수 있다. 그런 디렉토리는 B 트리로서 구조화된 표에 단편들을 저장할 수 있다. 그런 구현에서, 각 행에 1 개의 단편이 저장되어, 그 단편으로의 경로가 각 행에 대한 키의 일부로서 사용되도록 할 것이다.

내비게이터는 또한 특정 동작에 관심이 없는 단편들을 효과적으로 스킵(skip)할 수 있다. 본 발명에 따라 직렬화된 단편들의 내비게이션은 열린 네스팅 레벨들의 수, 또는 서브유형 수를 추적하는 것을 포함할 것이다. 일단 내비게이터가 원하는 네스팅 레벨이나 서브유형에 도달하면, 내비게이터는 그 레벨이나 서브유형에서 단편들의 수를 카운트할 것이다. 그런 단편은 그 자체가 네스팅의 새로운 레벨을 시작할 수 있다.

단편-기반 포맷으로 직렬화된 객체들의 멤버들의 위치를 파악하는 이점들에 추가하여, 기본 멤버들로의 액세스는 다음의 간단한 동작을 포함할 수 있다. 첫번째, 내비게이터는 이진 단편의 위치를 파악할 수 있다. 상술된 바와 같이, 기본 멤버들은 그런 단편에 저장되어 이득이 된다. 다음, 요구되는 멤버는 표준의, 최적화된 레코드 분해 코드를 사용하여 추출될 수 있다. 그것은 또한 표준의, 최적화된 레코드 구성 코드를 사용하여 업데이트될 수 있다. 이 간단한 동작은 한 개의 데이타베이스 열에 편리하게 저장될 수 있는 직렬화된 객체의 기본 멤버들의 위치를 높은 성능으로 파악하기 위해 제공된다. 이 방식으로 멤버의 위치파악을 허용하는 이점은, 위에 언급된 바와 같이, 멤버들은 전체 호스트 객체를 실체화할 필요없이 업데이트될 수 있다는 점이다. 이것은 전체 객체를 실체화하지 않고 단편이나 단편들의 시퀀스의 교체를 허용한다. 각 단편은 자체-포함(self-contained)일 수 있고, 본 발명은 단편 시퀀스의 식별자가 네스팅 단편의 시작과 종료기 단편의 존재이도록 구성될 수 있다. 이것은 다른 어떤 곳에 길이들을 고정시키지 않고 업데이트들을 수행하도록 하며, 표준 레코드-포맷 직렬화의 오프셋 표들을 피한다.

본 명세서에 기재된 기술들에 따라 생성된 단편들의 스트림의 저장은 LOB로서 단편들의 스트림을 저장하여 수행될 수 있다. 그런 LOB는 키가 오프셋 위치인 트리-구조의 저장 포맷을 가질 수 있다. 단편들의 스트림을 저장하는 이 기술은 LOB의 크기에 따른 예측가능한 삽입 및 삭제 시간을 제공한다. 그것은 또한 LOB의 단지 일부들만을 업데이트하도록 한다. 단편들의 직렬화된 객체들에 대한 온-와이어(on-wire) 포맷은 단편 헤더들의 형태에 대해 온-디스크(on-disk) 포맷과 동일하다. LOB와 FS 단편들이 아닌 단편들인 경우, 온-와이어 대 온-디스크인 단편들에 대한 변경을 전혀 할 필요가 없다. 본 발명의 이 양태는 객체들이 와이어로 신속히 복사되도록 하여, 한 위치에서 다른 위치로 객체들을 전송하는 속도에 높은 이득을 제공한다. 그러나, 단편 내용들은 추가 유연성을 제공하기 위해 LOB와 FS 단편들에 대해 다를 수 있음을 주목한다. 본 발명의 이 양태는 잠재적 단편 유형들의 요약과 함께 위에 설명되었다.

단편-직렬화된 객체들에의 동작

주어진 포맷으로 직렬화된 객체에 동작들을 수행하는 단순성, 효율성, 및 유연성은 직렬화 포맷의 성능을 평가하는 효과적 기준들이다. 본 명세서에 기재된 바와 같이 본 발명의 실시예들은 이 관점에서 높은 이득들로 특성화된다. 이것은 동작들이 이 섹션에 제공된 기술들을 사용하여 수행될 때 특히 사실일 것이다. 그러나, 동작들의 다음 리스트는 본 발명의 기술들에 따라 직렬화되는 객체들에 대해 가능한 동작들의 전체 리스트인 것으로 고려되지 않으며, 동작 기술들의 설명들이 그런 동작들을 수행하는 유일한 방식인 것으로 고려되지도 않음을 주목한다. 다음 동작들은 그 동작들의 수행에서 임의의 순서나 시퀀스를 지시하기 위해서가 아니고, 참조의 편의를 위해 번호가 매겨진다. 그 보다는, 동작들의 각각은 독립적으 로, 또는 임의의 다른 동작들과 연결하여, 수행될 수 있다.

본 발명의 이점들 중의 하나는, 그것은 객체 내에 멤버들에 대한 고성능의 검색과 업데이트 능력들을 여전히 허용하면서, 도 9에서와 같이, 데이타베이스에서 표의 한 개의 열에 한 객체의 저장을 하도록 한다는 점이다. 이 관점에서, 도 9는 데이타베이스의 한 개의 열에 객체들의 분류를 도시한다. 본 명세서에 기재된 본 발명의 다양한 실시예들에 따라, 객체들은 레코드 포맷으로 기본 멤버들을 포함하는 제1 단편(이것은 세분화된 유료부하를 가진 회색 단편임), 및 이 설명에 기재되는 단편들 중의 임의의 것일 수 있는 후속 단편들로 직렬화된다. 직렬화된 객체들에의 동작들의 다음 설명에서, 본 발명의 실시예들이 데이타베이스의 한 열에 저장되는 시나리오를 위한 참조로서 도 9를 참조한다.

다음 동작들의 예는 일반적 UDT(User-Defined Type) 객체, 및 그런 객체의 직렬화를 위해 디자인된 본 발명의 특정 구현을 참조하여 설명될 것이다. 단편 스트림으로서 저장되는 UDT 객체에 수행될 수 있는 동작들에 대한 기본 알고리즘들이 제공된다.

동작 1: 그것의 경로를 사용하여 객체를 유일하게 식별함

UDT가 단편들의 시퀀스로서 저장될 때, 시퀀스의 각 단편은 '경로'에 의해 유일하게 식별될 수 있다. 경로는 단계들의 시퀀스이며, 여기서 각 단계는 다음 것들 중에 정확히 하나일 수 있다:

1. 기본 필드가 아닌 필드(이하 비기본 필드라 지칭됨)를 표시하기 위해 단편 ID를 명시하는 네스팅 단계: UDT의 각각의 비기본 필드에 유일한 단편 ID가 할 당된다. 단편 ID들은 1에서 시작한다. 이것은 다음을 포함한다:

큰 객체들(LOBs)의 내부 필드들 -무제한이거나 매우 긴 길이의 문자/이진 데이타와 같은-. 이들 필드들의 각각은 분리된 단편으로서 저장된다.

파일스트림들 내부의 필드들, 예를 들어, 파일이 실제 데이타를 포함하고 데이타베이스 외부에 존재하는 경우, 단지 파일로의 포인터. 이들 필드들의 각각은 분리된 단편으로서 저장된다.

다른 UDT(다른 UDT 내에 UDT를 네스팅하는 것은 또한 UDT들의 작성으로서 알려짐) 또는 다른 UDT들의 집합일 수 있는 것의 내부의 필드들. 예를 들어, UDT A는 유형 UDT B의 필드 b를 가질 수 있다. 이 경우 b는 한 개의 자체-종료기 단편으로서 저장될 수 있거나, B가 비기본 필드들을 가지거나 다른 UDT의 서브유형이면, 단편들의 시퀀스로서 저장될 수 있다.

단편 ID들을 할당할 때, 상위 유형들로부터 상속된 비기본 필드들을 고려할 필요는 없음을 주목한다. 그러므로, UDT Q가 UDT P의 서브유형이면, UDT Q의 비기본 필드들에 단편 ID들을 할당할 때, Q가 모든 그런 필드들을 상속하지만 P의 필드들이 고려되지는 않는다.

또한, UDT의 비기본 필드들은 그들의 단편 ID들의 증가순으로 놓여짐을 주목한다.

2. 깊이를 명시하는 상속 단계: 이것은 단편이 어느 서브유형 섹션에 위치되는지를 말한다. 기본 유형의 기본 및 비기본 필드들은 서브유형의 것들 전에 놓여 짐을 상기한다. UDT R은 UDT P의 서브유형인 UDT Q의 서브유형임을 가정한다. 유형 R의 객체의 레이아웃은 다음과 같을 것이다:

[P의 기본 필드들을 위한 단편들]

...P의 비기본 필드들을 위한 0 개 이상의 단편들...

[Q의 기본 필드들을 위한 단편들] //이것은 Q에 대한 섹션을 시작한다.

...Q의 비기본 필드들을 위한 0 개 이상의 단편들...

[필요하면 Q를 위한 종료기]

[R의 기본 필드들을 위한 단편] //이것은 R에 대한 섹션을 시작한다.

...R의 비기본 필드들을 위한 0 개 이상의 단편들...

[필요하면 R을 위한 종료기]

깊이 2를 명시하는 상속 단계는 Q를 위한 섹션을 지시할 것이고, 깊이 3을 명시하는 상속 단계는 R에 대한 섹션을 지시할 것이다. P에 대한 섹션을 지시하기 위한 상속 단계는 필요하지 않다.

3. 위치파악기를 명시하는 집합 멤버 단계: 위치파악기는 유일하게 집합의 멤버를 식별한다. 집합의 멤버들은 1로부터 시작하는 위치파악기들이 할당된다. 집합 멤버가 삭제될 때, 그것은 위치파악기들의 '간격(gap)'을 야기시키고, 후속 멤버 삽입은 위치파악기를 재사용한다. 그러므로, 멤버들이 삭제되지 않으면, N 멤버들을 가진 집합의 멤버들은 위치파악기 1에서 N을 가질 것이다. UDT A가 UDT C의 집합이면, 2 개 멤버들을 포함하는 유형 A의 객체는 다음과 같을 것임을 상기한다:

[집합의 시작을 지시하는 단편]

[멤버 1의 시작을 지시하는 단편] //이것은 멤버 1을 위한 위치파악기를 가진다.

...멤버 1의 네스트된 유형들 및 서브유형들을 위해 필요하면 0 개 이상의 단편들...

[필요하면 멤버 1을 위한 종료기]

[멤버 2의 시작을 지시하기 위한 단편] //이것은 멤버 2를 위한 위치파악기를 가진다.

...멤버 2의 네스트된 유형들, 서브유형들을 위해 필요하면, 0개 이상의 단편들...

[필요하면 멤버 2를 위한 종료기]

[집합을 위한 종료기]

멤버 1을 위한 위치파악기를 명시하는 집합 멤버 단계는 멤버 1에 대한 섹션을 지시하는 한편, 멤버 2를 위한 위치파악기를 명시하는 집합 멤버 단계는 멤버 2에 대한 섹션을 지시할 것이다.

복잡한 UDT의 임의의 단편은 네스팅 단계들, 위치파악기 단계들, 및 상속 단계들의 적절한 순열로 유일하게 위치될 수 있다.

S1, S2,...,Sn의 순서로 n 단계들로 구성된 경로는 S1.S2...Sn으로서 표현된다. 또한, P가 경로이면, P의 단계들의 수에 대해 size(P)라는 부호가 사용되고, P의 i번째 단계를 위해 P[i], 여기서 i > 0, 가 사용된다.

동작 2, 바이트 스트림에 대해 단편 스트림의 구현 데이타베이스들은 수년 동안 제한되고 제한되지 않은 길이들의 문자/이진 데이타를 지원해 왔다. 문자/이진 데이타의 최상위에 바이트 스트림 인터페이스들을 제공하는 것은 공지된 기술이다. 바이트 스트림 인터페이스는 다음과 같은 방법들을 포함한다:

1. 어떤 명시된 오프셋 's'에서 시작하는 'n' 바이트들을 읽는다.

2. 어떤 명시된 오프셋 's'에서 시작하는 'n' 바이트들을 삽입한다. 개념적으로, 오프셋 's'에서 시작하는 기존 데이타는 'n' 바이트만큼 쉬프트되고, 생성된 '간격'은 제공된 'n' 바이트에 의해 채워진다. 그러나, 바이트 스트림이 클 때, 구현들은 대량의 데이타를 실제로 쉬프트하지 않도록 충분히 영리하다. 그들은 바이트 스트림의 최상위에 구성된 인덱스 구조를 사용하여 그것을 성취한다.

3. 1의 변형, 여기서, 판독되는 데이타는 바이트 스트림 인터페이스를 지원하는 객체의 형태로 요구된다.

4. 2의 변형, 여기서, 삽입되는 새 데이타는 바이트 스트림 인터페이스를 지원하는 다른 객체의 형태로 제공된다.

5. 어떤 명시된 오프셋 's'에서 시작하는 'n' 바이트를 제공된 데이타로 교체한다. 제공된 데이타가 '비어 있을(empty)' 수 있고, 이 경우, 오프셋 's'에서 시작하는 'n' 바이트드을 제거하는 효과를 가져온다.

6. 5의 변형, 여기서, 새 데이타는 바이트 스트림 인터페이스를 지원하는 객체의 형태로 제공된다.

위의 리스트는 대표적인 것들로 의도된 것이지 전체가 아님을 주목한다. 전 에 언급한 바와 같이, UDT는 단편 스트림으로서 저장된다. 단편 스트림은 바이트 스트림의 최상위에 구현될 수 있다.

동작 3: 경로 정보로부터 단편의 위치파악. UDT를 나타내는 단편 스트림을 고려한다. 이 섹션은 단편의 경로가 주어지면 그것에서 단편의 위치를 파악하는 방법을 설명한다.

경로가 유효하면, 더 이상 트래버스(traverse)할 수 없고 단편이 발견되지 않은 것으로 고려될 수 있는 경우인 널 UDT를 중간에서 만났을 때를 제외하고, 경로에 대응하는 단편이 발견되어야 한다. 예를 들어, '부서' UDT 내의 '관리자(manager)' 필드를 찾을 때, '부서' 객체 자체에 대한 단편이 널 단편이면, 이 방법은 '관리자'에 대한 단편이 발견되지 않음을 지시하기 위해 거짓을 반환한다.

스키마 전개(schema evolution)는 경로가 유효하더라도 경로에 대응하는 단편이 생략될 수 있는 경우의 다른 상황을 나타냄을 주목한다. 여기에,

의 기본 알고리즘이 있다. 초기에,

객체의

는 빈 경로이고, 현재 단편은 제1 단편이다.

. 단편의 위치를 파악하는 것에 추가하여, "단계까지 진행한다(advance till step)"의 동작이 또한 사용될 수 있다. 이 방법은 다음 규칙들에 따라 2 개의 단계들을 비교한다. 첫번째, 제1 '네스팅 단계'의 단편 ID가 제2 '네스팅 단계'의 것보다 작으면, 제1 '네스팅 단계'는 제2 '네스팅 단계'보다 작다. 두번째, 제1 '상속 단계'의 깊이가 제2 '상속 단계'의 것보다 얕으면, 제1 '상속 단계'는 제2 '상속 단계'보다 더 얕다. 세번째, 제1 '위치파악기 단계'의 위치파악기가 제2 '위치파악기 단계'의 것보다 작으면, 제1 '위치파악기 단계'는 제2 '위치파악기 단계'보다 작다. 네번째, '네스팅 단계'는 항상 '상속 단계'보다 작다(서브유형들로부터의 필드들 이전에 모든 네스트된 필드들이 저장되므로). 최종적으로, '위치파악기 단계'는 '네스팅 단계' 또는 '상속 단계'와 비호환적 이고, 그런 비교를 시도하는 것은 오류이다. 예를 들어, 다음 알고리즘을 참조한다:

. 더욱이, 다음 단편 취하기(get next fragment) 동작이 다음과 같이 구현될 수 있다:

동작 4: 기본 필드의 선택. 기본 필드의 선택은 우선 단편의 경로를 사용하여 기본 필드를 포함하는 단편의 위치를 파악하는 것과 관련이 있다. 이 단편의 유료부하는 레코드 포맷으로 존재하며, 기본 필드를 가진다. 다음, 유료부하로부터 기본 필드를 추출하기 위해 표준 최적화된 레코드 조작 코드가 사용될 수 있다.

동작 5: 기본 필드의 업데이트. 기본 필드의 업데이트는 3 단계로 이루어질 수 있다. 첫번째, 기본 필드를 선택하는 것과 동일한 방식으로 단편의 경로를 사용하여 기본 필드를 포함하는 단편의 위치를 파악한다. 두번째, 그 단편의 유료부하를 복사하고, 표준 최적화 레코드 조작을 사용하여 새 값으로 업데이트될 필요가 있는 기본 필드의 오랜 값을 교체한다. 이것은 원래 유료부하보다 더 길거나 더 짧을 수 있는 새 유료부하를 제공한다. 세번째, 오랜 유료부하를 새 유료부하로 교체하여 단편을 업데이트한다. 이것은 단편의 길이를 증가시키거나 감소시킬 수 있으며, 그것의 길이는 대응하여 조정되어야 함을 주목한다.

동작 6: 전체 임베디드 UDT의 복사. 전체 임베디드 UDT의 복사는, 첫번째, 상술된

를 사용하여 임베디드 UDT의 경로로부터 임베디드 UDT의 시작을 표시하는 단편의 위치를 파악하는 것과 관련이 있다. 두번째, 아래 설명된

함수를 사용하여 임베디드 UDT에 속하는 단편들을 복사할 수 있다.

UDT의 복사에 추가하여,

함수가 다음 기본 알고리즘을 사용하여 채택될 수 있다:

더욱이, 계속되는 내비게이션 함수

는 이 기본 알고리즘을 따를 수 있다:

동작 7: 임베디드 UDT의 모든 단편들의 제거.

에 유사하게, 메소드

는 임베디드 UDT에 속하는 모든 단편들을 제거하기 위해 제공된다. 각 단편에 대해, 기반되는

클래스는 그 단편에 대한 바이트들을 제거하기 위해 사용될 수 있다. 단편이 기반되는 파일을 실제로 삭제하기 위한 파일스트림 단편이면, 특별 프로세싱이 필요하다.

동작 8: 임베디드 UDT를 새 UDT로 업데이트.

로서 발명자들에 의해 참조되는 알고리즘은, 첫번째, 임베디드 UDT의 위치를 파악하기 위해 그것의 경로를 사용할 수 있고, 다음,

를 사용하여 임베디드 UDT에 속하는 모든 단편들을 삭제할 수 있고, 마지막으로, 새 UDT에 대한 단편들을 읽어서 그들을 현재 위치에 삽입할 수 있다. 다시 말하면, 기반되는

클래스는 새 단편에 대한 바이트들을 배치시키기 위해 사용될 수 있다. 적절한 데이타로 파일이 생성될 필요가 있으므로, 특별 프로세싱이 파일스트림 단편을 삽입하기 위해 필요된다.

동작 9: 집합 멤버의 삽입. 객체 B를 나타내는

객체의 집합의 멤버로서,

객체의 형태로 제공되는 UDT 객체 A의 삽입을 고려한다. 다음 알고리즘은

로서 발명자들에 의해 참조된다: 첫번째, 집합으로의 경로를 사용하여 B의 집합의 위치를 파악한다. 두번째, 위치파악기와 삽입 위치를 찾는다. 앞서 언급한 바와 같이, 집합 멤버가 초기에 삭제되면, 그것은 위치파악기들에 '간격'을 만드는 결과를 가져온다. 임의의 그런 간격이 존재하면, 미사용된 위치파악기는 새 멤버에 할당되고, 모든 멤버들이 위치파악기들의 증가순으로 놓여지도록 그것이 삽입된다. 그렇지 않으면, 최종 멤버보다 1이 많고 그 최종 멤버 다음에 삽입되는 새 멤버에 위치파악기가 할당된다. A의 제1 단편은 그것에 위치파악기를 배치하기 위해 수정되어야 할 것임을 주목한다.

동작 10: 집합 멤버의 삭제.

로서 발명자들에 의해 참조되는 알고리즘은 그것의 위치파악기를 사용하여 삭제할 멤버를 명시할 수 있다. 삭제는, 첫번째, 그것의 경로를 사용하여 집합의 위치를 파악하는 것, 및 두번째로, 집합 내에 삭제할 멤버의 위치를 파악하는 것과 관련이 있다. 우리는 여기서 단지 위치파악기 단계를 다루고 있으므로, 이것은 그것의 경로가 주어지면 단편의 위치를 파악하는 더 단순한 문제임을 주목한다. 그러므로,

메소드에서처럼 유사한 논리가 이것을 위해 사용될 수 있다. 다음, 일단 삭제할 멤버에 속한 제1 단편에 위치되면,

을 호출한다.

동작 11: 전체 집합이나 한 개의 집합 멤버의 업데이트.

전체 집합을 다른 집합으로 교체하는 것은 임베디드 UDT를 다른 UDT로 교체 하는 것과 동일한 방식으로 수행된다. 유사하게, 일단 집합 멤버의 위치가 파악되면, 그것의 업데이트는 임베디드 UDT의 업데이트와 동일한 방식으로 수행될 수 있다.

동작 12: UDT의 복수 필드들의 선택 및 업데이트. 복수 필드들을 선택하고 업데이트할 때, 다음 최적화들이 수행된다: 첫번째, 선택들/업데이트들을 순서화한다. 2 개의 단계들의 비교 및 순서화는 위에서 설명되었다. 경로는 단계들의 문자열로서 고려될 수 있고, '사전적' 순서화가 경로들에 정의될 수 있다. 다음 알고리즘을 참조한다:

필드들은 그들을 포함하는 단편들로의 경로들의 증가순으로 선택되거나 업데이트된다. 이 순서화는 단편들이 단편 스트림에 나타나는 동일 순서임을 주목한다. 복수 기본 필드들은 동일 단편에서 위치파악될 수 있다. 그런 경우, 일단 그들을 포함하는 단편이 방문되면, 단편을 다시 방문할 필요가 없이, 표준 레코드 조작 코드가 모든 원하는 필드들을 효과적으로 선택하거나 업데이트하기 위해 사용된 다. 상술된 것을 수행하여, 복잡한 UDT에서도, 그 UDT의 모든 원하는 필드들을 선택하거나 업데이트하기 위해 그것의 단편 스트림에 대해 많아야 한 개의 패스(pass)가 요구된다.

동작 13: 현재 위치를 사용하기 위한

의 개선.

알고리즘의 이전 설명은 항상 단편 스트림의 시작에서 시작했다. 그러나,

는 선택되거나 업데이트될 필요가 있는 제1 필드를 포함하는 단편의 위치를 파악하기 위해서만 시작으로부터 시작할 필요가 있다. 선택되거나 업데이트될 필요가 있는 후속 필드들을 포함하는 단편의 위치를 파악하기 위해,

는 현재 위치에서 시작할 수 있다.

에 필요한 개선점들은 아래 간략하게 언급된다. 본 명세서에 2 개의 기본 경우들이 있다:

1.

, 즉,

의 모든 단계들은

의 것들과 매치하지만, 타겟 경로는 일부 추가 단계들을 가진다. 이 경우,

는

에 대해 반복으로부터 시작하는 대신

에 대한 반복으로부터 시작할 수 있다.

2. 일부

에 대해,

의 처음

단계들은

의 것들과 매치하지만,

번째 단계는 그렇지 않다. 이 경우, 경로들이 증가순으로 이미 정렬되었으므로,

는

이어야 함을 주목한다. 이 경우, 또한

는

에 대한 반복에서

으로부터 시작할 수 있다.

동작 14: 느린 실현(Lazy Materialization). 서버에서 클라이언트로 UDT의 직렬화를 전송할 때, 파일 스트림 필드들로부터 LOB 데이타와 파일 데이타를 전송 하는 것은 가장 시간 소비적인 요소인 경향이 있다. 그래서, 단편 스트림 관리자는 '느린 실현' 선택을 제공할 수 있다.

UDT의 직렬화가 느린 실현의 선택과 함께 요구되었을 때, '쿠키들(cookies)'은 LOB/파일스트림 데이타의 위치에 반환된다. 호출자는 LOB/파일스트림 단편의 경로 및 '쿠키'를 전달하여 전체 LOB/파일스트림 데이타를 후속적으로 요구할 수 있다. 경로와 쿠키는 LOB/파일스트림 데이타를 검색수취하기 위해 단편 스트림 관리자에게 충분한 정보를 제공할 것이다.

동작 15: 스키마 전개. 스키마 전개는, UDT의 필드들을 추가, 삭제, 및 수정하여(필드의 데이타 유형의 변경과 같은) UDT를 변경하거나, 새 UDT들을 정의하여 상속 계층도를 변경하는 것 등을 참조한다. 그런 변경들은 이미 지속적인 UDT의 인스턴스들에 영향을 미칠 것이다. 간단한 해결책은, 새 필드들이 추가될 때, 기존 필드들에 할당된 임의의 필드 ID들 및 단편 ID들은 동일하게 남아있도록 보장하는 것이다. 그 다음, UDT로의 새 필드들의 추가는 UDT의 임의의 기존의 지속적 인스턴스들을 수정하지 않고 지원될 수 있다.

최종적으로, 본 명세서에 기재된 다양한 기술들은 하드웨어나 소프트웨어와의 연결로, 또는 적절한 경우, 둘 다의 조합으로, 구현될 수 있음을 이해해야 한다. 그러므로, 본 발명의 방법들 및 장치, 또는 그들의 특정 양태들이나 부분들은, 플로피 디스크, CD-ROM, 하드 드라이브, 또는 임의의 다른 기계-판독가능 저장 매체와 같은, 실제 매체들에 구현되는 프로그램 코드(즉, 명령어들)의 형태를 띌 수 있고, 여기서, 프로그램 코드가 컴퓨터와 같은 기계에 의해 로드되고 실행될 때 , 기계는 본 발명을 실행하는 장치가 된다. 프로그램가능한 컴퓨터들에서의 프로그램 코드 실행의 경우, 컴퓨팅 디바이스는 일반적으로 프로세서, 프로세서에 의해 판독가능한 저장 매체(휘발성 및 비휘발성 메모리 및/또는 저장 요소들을 포함함 ), 적어도 한 개의 입력 디바이스, 및 적어도 한 개의 출력 디바이스를 포함한다. 본 발명의 사용자 인터페이스 기술들을 구현하거나 사용할 수 있는 한 개 이상의 프로그램들은, 예를 들어, 데이타 프로세싱 API, 재사용가능한 컨트롤, 또는 기타등등의 사용을 통해, 컴퓨터 시스템과 통신하기 위해 고수준의 프로시져 프로그래밍 언어(procedural programming language) 또는 객체 지향 프로그래밍 언어로 구현되는 것이 선호된다. 그러나, 프로그램(들)은, 원하면, 어셈블리 또는 기계어로 구현될 수 있다. 임의의 경우, 언어는 컴파일된 언어 또는 인터프리트된 언어일 것이고, 하드웨어 구현들과 결합될 수 있다.

실시예들의 예는 한 개 이상의 자립형 컴퓨터 시스템들의 컨텍스트로 본 발명을 사용하는 것을 참조하지만, 본 발명은 그렇게 제한적이 아니고, 그 보다는, 통신망이나 분산 컴퓨팅 환경과 같은, 임의의 컴퓨팅 환경과 연결하여 구현될 수 있다. 더욱이, 본 발명은 복수의 프로세싱 칩들이나 디바이스들로 구현될 수 있고, 저장도 유사하게 복수의 디바이스들에서 영향을 받을 수 있다. 그런 디바이스들은 자동차나 비행기와 같은 다른 시스템들에 병합되는 개인용 컴퓨터, 통신망 서버, 핸드헬드 디바이스, 슈퍼 컴퓨터, 또는 컴퓨터를 포함할 것이다. 그러므로, 본 발명은 임의의 한 개의 실시예에 제한되어서는 안 되고, 그 대신, 첨부된 청구범위에 따라 범위가 해석되어야 한다.

부록 A: 단편 유효화 프로세스

다음 알고리즘들은 단편들을 유효화하기 위해 사용될 수 있는 최상위 레벨의 컴퓨터 프로세스 커맨드들로 기재된다.

단편 유효화 코드를 위한 다른 레이아웃이 아래 기재되고, 여기서, 직렬화의 문법은 BNF(Backus Naur Form)로 설명된다.

인용부호 "" 내의 부호는 터미널(terminal)이다. 예를 들어, "자체-종료 빈 프래그(self-terminating bin frag)"는 터미널을 나타낸다. 다양한 터미널 부호들은 이전 섹션에서 정의되었다.

각괄호<> 내의 부호는 논-터미널(non-terminal)을 나타낸다. 예를 들어,

은 논-터미널이다.

중괄호{} 내의 부호는 부호가 0번 이상 반복될 수 있음을 지시한다. 예를 들어,

는

의 0개 이상의 인스턴스들이 있을 수 있음을 지시한다.

주석 단편들은 스트림의 어떤 곳에도 존재할 수 있다.

Claims (37)

1. 데이타 객체로서 함께 저장된 한 개 이상의 데이타 멤버들로서,

   복수의 순차적으로 저장된 바이트들; 및

   상기 복수의 순차적으로 저장된 바이트들 내에 나타난 적어도 한 개의 데이터 멤버 -상기 적어도 한 개의 데이타 멤버는 데이타 유형과 연관됨-; 및

   상기 적어도 한 개의 데이타 멤버의 상기 데이타 유형을 식별하기 위해 사용되는 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 유형 바이트 -상기 적어도 한 개의 유형 바이트는 상기 적어도 한 개의 데이타 멤버에 매우 근접하게 위치됨-

   를 포함하는 한 개 이상의 데이타 멤버들.
2. 제1항에 있어서, 상기 적어도 한 개의 데이타 멤버는 레코드 포맷으로 저장되고, 상기 레코드 포맷은 상기 적어도 한 개의 유형 바이트에 관련하여 상기 적어도 한 개 데이타 멤버에 대한 예측가능한 위치를 정의하는 한 개 이상의 데이타 멤버들.
3. 제1항에 있어서, 상기 적어도 한 개의 데이타 멤버의 길이를 식별하기 위해 사용되는 상기 복수의 순차적으로 저장된 바이트들의 적어도 1 길이 바이트를 더 포함하는 한 개 이상의 데이타 멤버들.
4. 제1항에 있어서, 상기 적어도 한 개의 데이타 멤버는 상기 데이타 객체와 연관된 데이타의 위치를 지시하고, 상기 위치는 위치 유형과 연관되고, 상기 복수의 순차적으로 저장된 바이트들의 적어도 한 개의 위치 바이트는 상기 위치 유형을 식별하기 위해 사용되는 한 개 이상의 데이타 멤버들.
5. 제1항에 있어서, 상기 적어도 한 개의 유형 바이트는 상기 복수의 순차적으로 저장된 바이트들의 제1 바이트이고, 상기 데이타 객체의 시작을 지시하는 한 개 이상의 데이타 멤버들.
6. 제5항에 있어서, 상기 적어도 한 개의 유형 바이트는 한 개의 유형의 데이타 객체를 지시하는 한 개 이상의 데이타 멤버들.
7. 제1항에 있어서, 상기 데이타 유형은, 큰 객체들("LOBs"), 큰 객체("LOB") 데이타 유형, 파일 스트림("FS") 데이타 유형 및 집합 요소 데이타 유형을 제외한 기본(primitive) 데이타 유형을 포함하는 그룹으로부터 선택되는 한 개 이상의 데이타 멤버들.
8. 제7항에 있어서, 상기 적어도 한 개의 데이타 멤버가 LOB들을 제외한 기본 데이타 유형과 연관되면, 상기 적어도 한 개의 데이타 멤버는 레코드 포맷으로 저 장되고, 상기 레코드 포맷은 상기 적어도 한 개의 유형 바이트에 관련된 상기 적어도 한 개의 데이타 멤버에 대한 예측가능한 위치를 정의하는 한 개 이상의 데이타 멤버들.
9. 제1항에 있어서, 상기 적어도 한 개의 유형 바이트는 상기 적어도 한 개의 데이타 멤버가 상기 데이타 객체의 유일한 멤버 또는 멤버들임을 지시하는 한 개 이상의 데이타 멤버들.
10. 제1항에 있어서, 상기 복수의 순차적으로 저장된 바이트들 내에 적어도 한 개의 집합 시작 바이트를 더 포함하고, 상기 적어도 한 개의 집합 시작 바이트는 상기 적어도 한 개의 집합 시작 바이트에 매우 근접하게 저장된 일련의 관련 데이타 멤버들의 시작을 지시하기 위해 사용되는 한 개 이상의 데이타 멤버들.
11. 제1항에 있어서, 상기 복수의 순차적으로 저장된 바이트들 내에 적어도 한 개의 종료기(terminator) 바이트를 더 포함하고, 상기 적어도 한 개의 종료기 바이트는 일련의 데이타 멤버들의 끝을 지시하기 위해 사용되는 한 개 이상의 데이타 멤버들.
12. 제1항에 있어서, 데이타 멤버들의 집합의 일부인 제1 데이타 멤버와 연관된 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 바이트를 더 포함하 고, 상기 적어도 한 개의 바이트는 상기 데이타 멤버들의 집합의 일부인 제2 데이타 멤버에 대해 정보를 제공하는 한 개 이상의 데이타 멤버들.
13. 제1항에 있어서, 상기 적어도 한 개의 데이타 멤버에 매우 근접하게 저장된 적어도 한 개의 이진 트리("btree") 번호를 더 포함하는 한 개 이상의 데이타 멤버들.
14. 적어도 한 개의 데이타 멤버로 구성된 데이타 객체들을 저장하거나 전송하는 방법으로서,

    복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 데이타 멤버를 나타내는 단계 -상기 적어도 한 개의 데이타 멤버는 한 개의 데이타 유형과 연관됨- ; 및

    상기 적어도 한 개의 데이타 멤버에 대한 유형 정보를 식별하기 위해 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 바이트를 전용(dedicating)하는 단계 -상기 적어도 한 개의 바이트는 상기 적어도 한 개의 데이타 멤버에 매우 근접하게 위치됨-

    를 포함하는 방법.
15. 제14항에 있어서, 상기 적어도 한 개의 데이타 멤버를 나타내는 단계는 레코드 포맷으로 수행되고, 상기 레코드 포맷은 상기 적어도 한 개의 유형 바이트에 관 련하여 상기 적어도 한 개의 데이타 멤버에 대한 예측가능한 위치를 정의하는 방법.
16. 제14항에 있어서, 상기 적어도 한 개의 데이타 멤버의 길이를 식별하기 위해, 상기 복수의 순차적으로 저장된 바이트들 중의 적어도 한 개의 바이트를 전용하는 단계를 더 포함하는 방법.
17. 제14항에 있어서, 상기 적어도 한 개의 데이타 멤버는 상기 데이타 객체와 연관된 데이타에 대한 위치를 지시하고, 상기 위치는 위치 유형과 연관되고, 상기 복수의 순차적으로 저장된 바이트들 중의 적어도 한 개의 위치 바이트가 상기 위치 유형을 식별하기 위해 사용되는 방법.
18. 제14항에 있어서, 상기 적어도 한 개의 바이트는 상기 복수의 순차적으로 저장된 바이트들 중의 제1 바이트이고, 상기 데이타 객체의 시작을 지시하는 방법.
19. 제14항에 있어서, 상기 적어도 한 개의 유형 바이트는 데이타 객체의 한 개의 유형을 지시하는 방법.
20. 제14항에 있어서, 상기 데이타 유형은 큰 객체들("LOBs"), 큰 객체("LOB") 데이타 유형, 파일 스트림("FS") 데이타 유형 및 집합 요소 데이타 유형을 제외한 기본 데이타 유형을 포함하는 그룹으로부터 선택되는 방법.
21. 제20항에 있어서, 상기 적어도 한 개의 데이타 멤버가 LOB들을 제외한 기본 데이타 유형과 연관되면, 상기 적어도 한 개의 데이타 멤버는 레코드 포맷으로 저장되고, 상기 레코드 포맷은 상기 적어도 한 개의 유형 바이트에 관련하여 상기 적어도 한 개의 데이타 멤버에 대한 예측가능한 위치를 정의하는 방법.
22. 제14항에 있어서, 상기 적어도 한 개의 유형 바이트는 상기 적어도 한 개의 데이타 멤버가 상기 데이타 객체의 유일의 멤버 또는 멤버들임을 지시하는 방법.
23. 제14항에 있어서, 상기 적어도 한 개의 집합 시작 바이트에 매우 근접하게 저장된 일련의 관련 데이타 멤버들의 시작을 표시하기 위해, 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 바이트를 전용하는 단계를 더 포함하는 방법.
24. 제14항에 있어서, 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 종료기 바이트를 더 포함하고, 상기 적어도 한 개의 종료기 바이트는 일련의 데이타 멤버들의 끝을 지시하기 위해 사용되는 방법.
25. 제14항에 있어서, 상기 데이타 멤버들의 집합의 일부인 제2 데이타 멤버에 대한 정보를 제공하는 것에, 상기 복수의 순차적으로 저장된 바이트들 내의 적어도 한 개의 바이트를 전용하는 단계를 더 포함하고, 상기 적어도 한 개의 바이트는 데이타 멤버들의 집합의 일부인 제1 데이타 멤버와 연관된 방법.
26. 제14항의 방법을 수행하는 명령어들을 포함하는 컴퓨터 판독가능 매체.
27. 제14항의 방법을 수행하는 명령어들을 포함하는 변조 데이타 신호.
28. 한 개 이상의 데이타 멤버들로 구성된 데이타 객체를 저장하거나 전송하는 방법으로서,

    복수의 순차적으로 위치된 바이트들을 적어도 한 개의 헤더 섹션(header section)과 적어도 한 개의 유료부하 섹션(payload section)으로 분리하는 단계 -상기 적어도 한 개의 헤더 섹션과 상기 적어도 한 개의 유료부하 섹션은 서로 근접하게 위치됨-;

    상기 유료부하 섹션 내에 적어도 한 개의 데이타 멤버를 나타내는 단계 -상기 적어도 한 개의 데이타 멤버는 한 개의 데이타 유형과 연관됨-;

    상기 헤더 섹션 내에 상기 데이타 유형을 나타내는 단계; 및

    상기 유료부하 섹션 내에 상기 적어도 한 개의 데이타 멤버를 레코드 포맷으로 배치시키는 단계 -상기 레코드 포맷은 상기 유료부하 섹션의 임의의 다른 멤버들에 관련하여 상기 적어도 한 개의 데이타 멤버에 대한 예측가능한 위치를 정의함-

    을 포함하는 방법.
29. 제28항에 있어서, 상기 적어도 한 개의 데이타 멤버는 기본 데이타 유형과 연관되는 방법.
30. 제28항에 있어서, 상기 헤더 섹션 내에 유료부하 길이를 나타내는 단계를 더 포함하는 방법.
31. 제28항에 있어서,

    상기 복수의 순차적으로 저장된 바이트들을 적어도 한 개의 제2 헤더 섹션과 적어도 한 개의 제2 유료부하 섹션으로 더 분리하는 단계 -상기 적어도 한 개의 제2 헤더 섹션과 상기 적어도 한 개의 제2 유료부하 섹션을 서로 근접하게 위치됨-;

    상기 적어도 한 개의 제2 유료부하 섹션 내에 상기 적어도 한 개의 제2 데이타 멤버에 대한 위치 정보를 나타내는 단계 -상기 위치 정보는 한 위치 유형의 위치를 명시함-; 및

    상기 제2 헤더 섹션의 상기 위치 유형을 식별하는 단계

    를 더 포함하는 방법.
32. 제31항에 있어서, 상기 적어도 한 개의 제2 유료부하 섹션 내에 LOB 유형의 데이타 멤버를 배치시키는 단계를 더 포함하는 방법.
33. 제31항에 있어서, 상기 적어도 한 개의 제2 유료부하 섹션 내에 FS 유형의 데이타 멤버를 배치시키는 단계를 더 포함하는 방법.
34. 제31항에 있어서, 상기 적어도 한 개의 제2 헤더 섹션 내에 유료부하 길이를 나타내는 단계를 더 포함하는 방법.
35. 제28항에 있어서,

    상기 복수의 순차적으로 위치된 바이트들을 적어도 한 개의 제2 헤더 섹션으로 더 분리하는 단계; 및

    상기 적어도 한 개의 제2 헤더 섹션에 거의 근접하게 위치된 관련 데이타 멤버들의 집합의 시작을 상기 적어도 한 개의 제2 헤더 섹션에 표시하는 단계

    를 더 포함하는 방법.
36. 제35항에 있어서, 상기 적어도 한 개의 제2 헤더 섹션 내에, 상기 관련 데이타 멤버들의 집합이 순서화되었는지 또는 비순서화되었는지를 지시하는 단계를 더 포함하는 방법.
37. 제28항에 있어서,

    상기 복수의 순차적으로 위치된 바이트들을 적어도 한 개의 제2 헤더 섹션으로 더 분리하는 단계; 및

    상기 적어도 한 개의 제2 헤더 섹션 내에 상기 데이타 객체의 끝을 표시하는 단계

    를 더 포함하는 방법.

Images