KR101153139B1 - 지속형 데이터 스토어를 생성하기 위한 방법 - Google Patents

Abstract

기초를 이루는 데이터 스토어에 기본적으로 의존하지 않고 데이터 객체를 데이터베이스에 유지하기 위한 일반적인 메커니즘이 제공된다. 데이터베이스의 구조가 어떻게 보여야 하는지를 알기 위한 프로그래머의 전문성에 의존하기보다, 데이터를 저장하기 위해 사용될 데이터베이스의 구조를 프로그래머가 정의하지 않고서 대응하는 데이터가 무엇을 위해 사용될지를 제안하는 속성을 이용하여 프로그래머에 의해 데이터 타입이 정의되고 장식된다. 그 후, 장식된 속성에 의해 제안된 요구를 만족시키기 위하여 데이터베이스가 동적으로 생성된다. 특히, 데이터를 액세스하기 위한 의도된 요구에 따라 많은 상이한 테이블이 생성된다. 이렇게 함으로써, 프로그래머가 데이터베이스 및 대응하는 데이터베이스 스키마에 관한 어떠한 특정 지식을 가질 것을 요구하지 않고서 원하는 결과를 제공하기 위하여 최적화된 데이터베이스가 생성될 수 있다.

데이터베이스, 관계 데이터베이스, 클래스, 객체, 데이터 스토어

Description

지속형 데이터 스토어를 생성하기 위한 방법{Durable Storage of .NET Data Types and Instances}

도 1a, 1b, 1c 및 1d는 대응하는 데이터 타입에 첨부된 장식에 따라, 한 특정 실시예에서 생성될 수 있는 타입 테이블의 집합을 도시하는 도면.

도 2a 및 2b는 대응하는 데이터 타입에 첨부된 장식에 따라, 한 특정 실시예에서 생성될 수 있는 타입 테이블의 또다른 집합을 도시하는 도면.

도 3은 본 발명의 일 실시예에 따라 데이터를 저장하기 위한 방법에 대응하는 흐름도.

도 4는 본 발명의 방법이 실행될 수 있는 적합한 컴퓨팅 환경의 일 실시예를 도시하는 도면.

<도면의 주요부분에 대한 부호의 설명>

310: 저장될 데이터 타입 식별

320: 데이터를 저장하기 위해 사용될 데이터베이스 스키마 결정

330: 데이터 타입을 저장하기 위한 데이터 스토어가 이미 존재하는지 결정

340: 데이터베이스 구조(들) 생성

350: 데이터 구조(들)에 저장될 데이터 객체 획득

360: 데이터가 이미 저장되었는지 결정

370: 이미 저장되지 않았다면 데이터를 저장

380: 새로운 데이터를 무시하거나 저장된 데이터를 수정

본 발명은 컴퓨팅 시스템의 분야에 관한 것이며, 보다 상세하게는, 데이터베이스 구조를 생성하고, 데이터 타입, 특히, .Net 데이터타입에 관련된 장식(adornment)에 응답하여 데이터베이스에 데이터를 저장하기 위한 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다.

데이터를 저장하기 위해 사용될 수 있는 여러 상이한 시스템 및 툴이 존재한다. 데이터 저장은, 예를 들어, 인지된 필요에 기초하여 데이터를 저장하기 위한 상이한 유형의 데이터베이스 구조들을 프로그래머가 선택할 수 있게 하기 위하여 구성되는 데이터베이스 툴의 사용을 포함할 수 있다. 다른 것들도 또한 존재하지만 그러한 하나의 툴은 Jet SQL 데이터베이스에 따라 데이터를 저장하는 Access를 포함한다. 그러나, 이러한 예에도 불구하고, 여러 상이한 유형들의 관계 데이터베이스를 위한 다양한 다른 유형의 데이터 저장 툴들이 존재한다는 점을 잘 알 것이다.

그러나, 기존의 데이터베이스 툴들의 한 가지 문제점은, 프로그래머들이 데이터베이스, 및 그들이 생성되고 있는 특정 구현에 최상으로 알려진 성능을 제공하 기 위하여 데이터베이스가 어떻게 생성 및 조직되어야 하는지에 대한 비교적 정교한 지식을 가질 것을 필요로 한다는 점이다. 예를 들어, 프로그래머는 데이터베이스에 제공될 테이블, 할당된 메모리 및 기타 저장 구조의 상이한 유형들을 식별할 필요가 있을 것이다.

그러나 저장된 데이터에 대한 요구는 변동할 수 있으므로, 데이터베이스 구조를 생성하기 위한 기존의 패러다임은 다소 제한된다. 특히, 데이터를 저장하기 위해 알려진 요구, 및 그러한 요구를 최상으로 서비스하는 방법에 대한 프로그래머의 제한된 지식에 기초한 데이터베이스의 생성은 데이터베이스의 사용을 과도하게 제한할 수 있고, 데이터베이스가 앞으로 상이한 요구를 서비스하도록 쉽게 맞춤화되는 것을 방지할 수 있다.

특히, 데이터베이스가 생성될 때 미리 알려지지 않거나 설립된 데이터베이스와 호환되지 않는 상이한 시스템으로부터의 상이한 유형의 데이터를 저장하기 위해 데이터베이스가 필요할 수 있다. 설립된 데이터베이스 구조는 또한 단지 SQL 이외에도 상이한 유형의 관계 데이터베이스에 대해 사용되도록 유연성을 제공할 필요가 있을 수 있다. 그러나, 기존의 기술들은 데이터베이스를 정의하는 단일체적인 코드를 재작성해야만 이러한 유연성을 제공한다.

객체를 관계 데이터베이스에 저장하는 것이 직면한 또다른 문제점은 프로그래머가 객체들을 관계 데이터베이스에 저장하는 한편, 나중에 데이터 객체들이 액세스될 때 저장의 성능에 부정적으로 영향을 끼치지 않도록 하기 위한 방식으로 클래스 계층을 번역하기 어렵다는 점이다. 예를 들어, 만약 여러 상이한 유형의 클 래스들이 동일한 베이스 클래스에 대응한다면, 하나의 단일체적인 데이터베이스 구조에 개별적인 클래스들 각각을 저장하는 것은 이치에 맞지 않을 수 있다. 마찬가지로, 개별적인 클래스들 각각을 상이한 구조에 완전히 개별적으로 저장하는 것은 이치에 맞지 않을 수 있다. 이러한 예 둘 모두 데이터의 이어지는 질의 동안 비효율성 문제를 발생시킬 수 있다.

따라서, 임의의 데이터 구조를 저장하고, 요구 시 데이터 스토어의 기초를 이루는 구조에 기본적으로 의존하지 않고서 그들을 검색하기 위한 일반적인 방식이 요구된다.

본 발명은 일반적으로 기초를 이루는 데이터 스토어 또는 그것의 규칙 또는 특성에 기본적으로 의존하지 않고서 데이터 객체를 데이터베이스에 유지하기 위한 일반적인 메커니즘을 제공하는 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다. 대신, 본 발명은 데이터 저장 기술에 근본적인 변화(paradigm shift)를 제공한다. 특히, 원하는 결과를 획득하기 위하여 데이터베이스의 구조가 어떻게 보여야 하는지를 알기 위해 프로그래머의 전문성에 의존하기보다, 본 발명은 데이터가 무엇을 위해 사용되는지에 초점을 두며, 그 후 원하는 결과를 제공하기 위하여 최적화된 데이터베이스를 생성한다.

일 실시예에 따르면, 프로그래머는 데이터를 저장하기 위해 사용될 데이터베이스의 구조를 정의하지 않고서, 대응하는 데이터가 무엇을 위해 사용될지를 제안하는 속성들을 이용하여 데이터 타입을 정의하고 장식한다. 그 후, 장식된 속성들 에 의해 제안된 요구를 만족시키기 위해 데이터베이스가 동적으로 생성된다. 특히, 데이터를 액세스하기 위한 의도된 요구에 따라 많은 상이한 테이블이 생성된다. 소정 실시예에 따르면, 데이터 저장 중복을 최소화하고 데이터를 액세스하기 위해 의도된 요구를 만족시키기 위하여 데이터베이스의 성능을 증가시키는 방식으로 데이터베이스 구조 및 테이블이 생성된다. 이러한 데이터베이스 테이블의 생성은 상이한 유형의 데이터 구조 또는 데이터베이스에 관한 어떠한 특별한 지식도 가질 필요가 없는 프로그래머에게 투명하다. 대신에, 프로그래머는 대응하는 데이터를 액세스하기 위해 단지 알려진 요구에 기초하여 데이터 타입을 식별하는 코드를 개발할 수 있다.

만약 나중에 데이터를 액세스하기 위한 요구가 변경되면, 데이터 타입이 수정되거나 삭제될 수 있고, 새로운 데이터 타입이 생성될 수 있으며, 그것은 데이터베이스의 기초를 이루는 구조가 데이터베이스에 대응하는 코드의 단일체적 부분이 곳곳에서 수정될 것을 필요로 하지 않고서 동적으로 적절히 갱신되도록 허용할 것이다. 즉, 본 발명은 데이터베이스 구조의 모듈 생성을 가능하게 하는 수단을 제공한다.

본 발명의 부가적인 특성 및 이점들은 후술되는 상세설명에 언급될 것이고, 상세설명으로부터 부분적으로 명백해질 것이며, 또는 본 발명의 실행에 의해 학습될 수 있다. 본 발명의 특성 및 이점은 첨부되는 특허청구범위에 특히 지적된 기구 및 조합의 수단에 의해 실현 및 획득될 수 있다. 본 발명의 이러한 특성 및 기타 특성들이 후술되는 상세설명 및 첨부된 특허청구범위로부터 더욱 완전히 명백해 질 것이며, 또는 이후에 언급된 바와 같은 본 발명의 실행에 의해 학습될 수 있다.

본 발명의 상기 언급된 것들 및 기타 이점 및 특성이 획득될 수 있는 방식을 기술하기 위하여, 상기 간략히 기술된 본 발명의 더욱 특정한 설명이 첨부된 도면에 도시된 특정 실시예들을 참조하여 제공될 것이다. 이러한 도면들은 단지 본 발명의 전형적인 실시예들을 도시하며, 따라서 본 발명의 범위를 한정하는 것으로 여겨져서는 안 된다는 것을 이해하여야 하며, 본 발명은 첨부되는 도면들의 사용을 통해 부가적으로 특수하게 및 상세하게 기술되고 설명될 것이다.

본 발명은 데이터를 저장하고 대응하는 데이터베이스 구조를 생성하기 위한 방법 및 시스템 둘 모두에 확장된다. 본 발명의 실시예들은 하기에 보다 상세히 논의된 바와 같이 다양한 컴퓨터 하드웨어를 포함하여 특수용 또는 범용 컴퓨터를 포함할 수 있다.

본 명세서에 기술된 바와 같이, 본 발명의 실시예들은 데이터를 저장하기 위해 데이터베이스 구조가 어떻게 생성되는지에 관한 어떠한 특별한 지식도 필요로 하지 않고서 데이터에 대해 의도된 사용에 기초한 속성들을 가지고 데이터 타입이 장식되는 방법을 포함한다. 그 후 장식된 데이터 타입에 의해 결정된 요구에 따라 적합한 데이터베이스 저장 테이블이 생성된다. 그 후 테이블은 대응하는 데이터로 채워질 수 있고, 적절한 어플리케이션에 의해 질의될 수 있다. 데이터베이스 구조의 생성이 데이터의 의도된 사용에 기초하고, 데이터베이스의 어떠한 지식 요구도 배제하기 때문에, 프로그래머가 데이터베이스 및 데이터베이스 구조에 관해 가질 수 있는 어떠한 지식의 결핍에 관계없이 데이터베이스의 성능을 최적화하도록 데이 터베이스 구조가 생성된다는 점을 잘 알 것이다. 이것은 데이터베이스 구조를 생성하기 위한 선행기술 시스템에 대한 근본적인 변화 및 개선을 나타낸다는 점 또한 잘 알 것이다.

본 발명의 범위 내의 실시예들은 또한 컴퓨터-실행가능 명령어를 전달하거나 저장하고 있기 위한 컴퓨터-판독가능 매체를 포함한다. 그러한 컴퓨터-판독가능 매체는 범용 또는 특수용 컴퓨터에 의해 액세스될 수 있는 임의의 가용 매체일 수 있다. 제한을 가하지 않는 예로서, 그러한 컴퓨터-판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 기타 광 디스크 저장장치, 자기 디스크 저장장치 또는 기타 자기 저장 장치, 또는 컴퓨터-실행가능 명령어 또는 데이터 구조의 형태로 원하는 프로그램 코드 수단을 전달하거나 저장하기 위해 사용될 수 있고 범용 또는 특수용 컴퓨터에 의해 액세스될 수 있는 임의의 기타 매체를 포함할 수 있다. 네트워크 또는 또다른 통신 연결(하드웨어, 무선이든지 또는 하드웨어나 무선의 조합이든지)을 거쳐 정보가 컴퓨터로 이동되거나 제공될 때, 컴퓨터는 연결을 당연히 컴퓨터-판독가능 매체로서 여긴다. 따라서, 임의의 그러한 연결은 당연히 컴퓨터-판독가능 매체라고 불린다. 상기의 조합들 또한 컴퓨터-판독가능 매체의 범위 내에 포함되어야 한다. 컴퓨터-실행가능 명령어는, 예를 들어, 범용 컴퓨터, 특수용 컴퓨터, 또는 특수용 프로세싱 장치가 특정 함수 또는 함수들의 그룹을 수행하도록 하는 명령어 및 데이터를 포함한다.

.NET 데이터 타입 및 인스턴스에 대한 지속형 저장

본 발명의 일 실시예에 따르면, 프로그래밍 동안에 정의된 데이터 타입에 위 치된 장식에 응답하여, 데이터베이스 테이블과 같은(이것으로 제한되지 않음) 데이터베이스 구조의 생성을 가능하게 하기 위하여 대응하는 모듈에 .NET 데이터 타입 및 인스턴스에 대한 지속형 저장이 제공된다.

데이터 타입에 위치된 장식은 임의의 요구 또는 바램에 따라 변할 수 있다. 프로그래머가 이어서 생성될 데이터베이스 구조에 관한 어떠한 특별한 지식을 갖지 않을지라도 나중에 데이터베이스 구조의 생성을 제어하는 데에 사용될 수 있도록 하기 위한 방식으로, 프로그램에 의해 작성된 코드 세그먼트 내의 데이터 타입에 장식이 어떻게 첨부될 수 있는지를 설명하기 위한 소정 예들이 이제 제공될 것이다.

첫번째 예에서, 제목, 앨범 분야, 아티스트의 리스트 및 노래의 리스트를 포함하는 클래스 타입으로서 앨범이 기술된다. 노래 각각 또한 제목, 길이 및 앨범을 갖는 클래스 타입으로서 식별된다. 마지막으로, 아티스트는 이름, 사진 및 팬 페이지 URI을 포함하는 클래스 타입으로서 식별된다.

상기 예에 의해 더 나타나 있는 바와 같이, 클래스 타입에 대응하는 데이터 객체들 중 몇몇은 특별한 속성들로 장식된다. 예를 들어, [CLSIBackPointer(album)] 속성은 앨범 필드 또는 객체가 동일한 앨범에 관련될 수 있는 여러 상이한 노래들에 대한 백 포인터(back pointer)를 포함한다는 것을 나타낸다. 이것은 하기에 도 1을 참조하여 더욱 상세히 기술될 것이다.

보여진 또다른 장식은 아티스트 클래스에 관련된 [CLSIIndex] 속성을 포함하며, 이것은 아티스트 클래스가 질의될 수 있어야 한다는 것을 나타낸다. 이 장식에 대한 하나의 이유는 데이터베이스의 성능을 증가시키기 위한 것이다. 특히, 만 약 데이터베이스가 특정 용어에 대한 질의를 허가할 것이라고 알려지면, 어떤 용어들이 질의되도록 의도되는지를 나타내는 것이 유용할 수 있다. 이러한 식으로, 데이터 구조가 생성될 때, 하기에 보다 상세히 기술된 바와 같이, 질의될 것으로 알려진 용어들에 대한 검색을 최적화하기 위한 방식으로 생성될 수 있다.

이제 도 1a-1d에 주목하면, 이들은 본 발명의 방법에 따라 생성될 수 있으며, 지속형 저장 모듈에 제공되는 코드에서 정의된 데이터 타입 및 장식에 기초하는 데이터베이스 테이블을 포함하는 특정 데이터베이스 구조를 도시한다.

도시된 바와 같이 네 개의 테이블이 생성된다. 첫번째 테이블인 앨범 테이블(100a)은 상기 예에서 식별된 앨범 타입에 대응하고, 하기에 언급된 바와 같이 레코드 번호 열(130a) 및 아티스트 열(140a)과 함께, 제목 필드(110a) 및 분야 필드(120a)를 포함한다. 이러한 상이한 필드들은 상기 기술된 코드에서 제공된 객체들에 대응한다.

별도의 노래 테이블(100b)도 코드에 의해 정의된 제목, 길이 및 앨범에 각각 대응하는 필드들(110b, 120b, 130b)을 가진다. 길이 필드(120b)는 그것이 속하는 노래에 대응하는 임의의 시간 길이 데이터를 포함할 수 있다.

아티스트 테이블(100c)은 상기 제공된 예에서 아티스트 클래스 타입의 설명에 대응하는 이름 필드(110c), 사진 필드(120c), 및 URI 필드(130c)를 포함한다. 사진 필드(120c)는 예를 들어 아티스트에 대응하는 그래픽 이미지에 대한 포인터를 포함할 수 있고, URI 필드(130c)는 팬 페이지와 같이 아티스트에 대응하는 문서 또는 웹 페이지에 대한 링크를 포함할 수 있다.

마지막으로, 둘 모두 고유 식별자를 보유하도록 타입화된 두 개의 열을 포함하는 컬렉션 테이블(100d)이 제공된다. 첫번째 열(110d)은 컬렉션의 식별자를 나타내고, 그 열을 참조하는 인스턴스들의 필드들(이 경우에는 앨범 테이블(100a)로부터의 앨범들)에 의해 포인팅된다. 두번째 열(120d)은 컬렉션의 부분인 인스턴스의 식별자, 이 경우에는 아티스트의 식별자이다. 따라서, 하나의 컬렉션은 자신이 포함하는 인스턴스들의 수만큼의 행을 컬렉션 테이블에 가질 것이지만, 그러한 모든 행이 주어진 컬렉션을 나타내는 동일한 고유 식별자를 갖는다. 따라서, 컬렉션에 대한 포인터 필드는 해당 컬렉션 인스턴스를 나타내는 행의 고유 식별자를 위치시킴으로써 표현될 수 있다. 이것은, 앨범 객체에 의해 포인팅되는 별개의 아티스트 컬렉션 각각이 컬렉션 테이블에서 하나 이상의 행으로서 표현될 것이며, 그 행들 각각의 두번째 열은 아티스트 테이블 내의 한 행을 포인팅할 것임을 의미한다. 예를 들어, 본 예에서, 컬렉션 ID 1(앨범 1에 관련됨)은 아티스트 엘리먼트 21 및 아티스트 엘리먼트 23으로 링크된다. 컬렉션 ID는 또한 상호-참조를 위해 앨범 테이블(100a)에서도 식별된다.

아티스트 타입의 이름 필드가 상기 기술된 바와 같이 적절한 장식을 갖는 고유 식별자로서 속성화되면, 아티스트 이름은 컬렉션 테이블에서 아티스트 테이블 내의 행들을 포인팅할 수 있는 고유 식별자를 나타낼 수 있다. 그러나, 만약 아티스트 타입의 이름 필드가 고유 식별자로서 속성화되지 않으면, 포인터는 아티스트 이름 대신에, 대응하는 아티스트 테이블의 식별자를 다시 포인팅할 것이다. 본 예에서, 이것은 레코드 번호를 사용하여 행해진다.

노래 클래스의 제목 필드 및 아티스트 클래스 타입의 이름 필드가 [CLSIIndex] 속성을 가지고 장식되었기 때문에, 노래 클래스 및 아티스트 클래스에 대응하는 데이터베이스 구조(예를 들어, 테이블)는 제목 열과 이름 열에서 각각 소팅되고 신속히 질의될 수 있는 방식으로 형성되며, 데이터베이스는 대응 데이터베이스 테이블에 저장된 행들 모두를 질의할 필요가 없다는 점을 알아야 한다.

주어진 클래스에 관련된 데이터베이스 테이블은 테이블 내의 각 행마다 고유 식별자를 제공하는 숨겨진 레코드 번호(예를 들어, 130a, 140b, 140c)를 포함할 수 있다.

용어 또는 객체를 검색하는 동안, 데이터베이스는 레코드 번호(130a)에 기초하여 모든 레코드를 순차적으로 검색할 수 있다. 그러나, 만약 클래스 필드가 이전에 식별되었고, 질의되도록 의도된다는 것을 나타내는 [CLSIIndex] 속성과 같은 속성으로 장식되었다면, 검색을 최적화하기 위하여 (알파벳 순서로, 또는 임의의 다른 방식으로) 소팅될 수 있도록, 노래 테이블의 제목 열 및 아티스트 테이블의 이름 열과 같은 속성 필드에 대응하는 열에 대해 대응 인덱스 데이터 구조가 생성될 수 있다. 따라서, 프로그래머가 데이터베이스에 관한 어떠한 특별한 지식을 통해 데이터 구조를 형성하지 않고서도, 질의가 최적화될 수 있다.

마찬가지로, 앨범 클래스에서 노래 필드에 관련된 백 포인터 장식은, 노래 컬렉션이 앨범 인스턴스에 의해 소유되며 노래 타입 내의 앨범 필드는 소유하는 앨범에 대한 백 포인터의 기능을 한다는 것을 나타낸다. 따라서, 주어진 앨범에 속하는 노래들은 지정된 앨범을 식별하는 앨범 열을 갖는 노래 테이블을 질의함으로 써 식별될 수 있다. 역으로, 앨범 열은 주어진 노래가 속하는 앨범을 식별하기 위해 사용될 수 있다. 그 후, 식별된 앨범은 기타 테이블들(예를 들어, 100c)을 사용하여 앨범의 아티스트에 대응하는 기타 정보를 식별하기 위하여 사용될 수 있다.

이러한 식으로, 노래 테이블(100b)은 앨범 테이블(100a)에 독립적으로 질의될 수 있으므로, 앨범 테이블(100a)은 노래 테이블(100b)에 나열된 노래들 각각에 대한 길이 정보를 저장할 필요가 없다. 이것은 앨범 테이블(100a)을 질의할 때의 성능을 개선할 수 있다는 것을 잘 알 것이다. 마찬가지로, 노래 테이블(100b)은 그것이 속하는 앨범에 관련된 분야 및 아티스트 이름 정보 모두를 저장할 필요가 없으므로, 노래 테이블(100b)에 대한 질의도 최적화된다. 이것은 테이블의 상호-참조가 필요한 정보 모두를 쉽게 제공할 수 있기 때문이다.

이제 부가적인 유형의 장식을 보여주기 위하여 상품 주문의 고객에 관한 또다른 예가 제공될 것이다. 그렇지만, 전술한 예 뿐 아니라 이 예 또한 단지 예시이며, 그러므로 생성될 수 있는 데이터베이스 구조의 유형 또는 사용될 수 있는 장식 속성들의 유형에 관하여 본 발명을 제한하는 것으로서 여겨져서는 안 된다는 것을 잘 알 것이다.

다음 예에서, 고객 및 상품 주문 클래스가 생성된다.

전술한 예에서, 소정의 새로운 장식이 제공된다. 예를 들어, 고객 클래스의 전화 번호 필드를 장식하는 [CLSIIdentity] 속성은 전화 번호가 해당 고객 타입에 대한 고유 키를 나타내야 한다는 것을 나타내기 위하여 제공된다.

[CLSISingleRef] 속성은, 고객과 고객 주소 사이에 일대일 관계가 존재할 것이 의도된다는 것을 나타내기 위하여, 고객 클래스의 주소 필드에 제공된다.

[CLSIBackPointer(customer)]를 포함하는 또다른 속성은 고객 클래스의 상품 주문 필드에 대해 장식된다. 이 속성은 상품 주문이 그 주문을 행하는 고객으로의 백 포인터로서 제공되도록 의도된다는 것을 나타낸다. 이것은 도 2에 제공된 예의 관점에서 보다 명백히 이해될 수 있다.

도 2a 및 2b에 도시된 바와 같이, 고객 테이블(200a) 및 상품 주문 테이블(200b)은 각각 상기의 예시적인 코드 세그먼트에서 정의된 대응 필드들(210a, 220a, 230a 및 210b, 220b, 230b)과 함께 생성된다. 이들 테이블(200a 및 200b) 또한, 테이블(100a, 100b 및 100c)과 마찬가지로, 데이터베이스 구조가 어떻게 형성되는지에 관한 어떠한 특별한 지식없이 코드 세그먼트에 제공된 정의 및 장식에 따라 생성되었다. 대신에, 정의 및 장식은, 저장된 데이터가 무엇을 위해 사용될 것인지 또는 그것이 어떻게 액세스되거나 질의되어야 하는지에 대한 힌트를 제공하기만 하면 된다.

전술한 예에서, [CLSIIdentity] 속성의 장식은 대응하는 필드(전화 번호)가 해당 고객 타입에 대한 고유 키를 나타내야 한다는 것을 나타내기 위하여 제공된다. 이것은, 예를 들어, 테이블 내의 각 행마다 특별한 레코드 번호(130a)(도 1)를 저장해야 한다는 요구사항을 최소화하는 데에 유용할 수 있다. 특히, [CLSIIdentity] 속성으로 장식된 필드는 각 대응하는 행에 대한 고유 식별자로서 사용될 수 있다. 이것은 상품 주문 테이블(200b)에서 고객을 나타내기 위하여 전화 번호(220a)가 사용되는 도 2에 도시된다.

기타 실시예들에서, 필드들의 조합이 행에 대한 고유 식별자를 나타낼 수 있 도록, 필드들의 조합 또한 [CLSIIdentity] 속성으로 장식될 수 있다.

상기에 식별된 [CLSISingleRef] 속성은, 고객과 고객 주소 사이에 일대일 관계가 존재할 것이 의도된다는 것을 나타내기 위하여 고객 클래스의 주소 필드에 제공된다. 이러한 점에서, 고객 주소 필드(230a)는 고객에 대응하는 실제 주소 스트링으로 채워질 수 있고, 또는 대안적으로 또다른 테이블에 저장된 주소 데이터를 포인팅할 수 있다.

상기에 개괄적으로 설명된 백 포인터 속성 [CLSIBackPointer(customer)] 또한 지난 예에서 고객 클래스 타입에 대한 상품 주문 필드에 대해 장식되었다. 따라서, 도 1을 참조하여 기술된 바와 같이, 백 포인터는 상품 주문 테이블에 나열된 고객이 고객 테이블(200a)을 다시 참조할 수 있게 한다. 따라서, 하나의 테이블이 고객의 상품 주문 뿐 아니라 고객에 대응하는 데이터 항목들 각각을 반드시 유지할 필요는 없다. 대신에, 구매되고 있는 항목의 상세한 설명 및 대응하는 SKU 코드가 고객 테이블(200a)과 별개로 유지될 수 있고, 요구될 때 상품 주문에 대응하는 고객을 찾아봄으로써 액세스될 수 있다. 이것은 상기에 기술된 바와 같이 데이터베이스의 의도된 요구에 따라 데이터베이스의 성능을 개선할 수 있다는 점을 잘 알 것이다. 훨씬 더 중요한 것은, 프로그래머는 데이터베이스 테이블이 어떻게 생성되는지를 알거나 이해할 필요가 없었다는 점이다. 대신에, 프로그래머는 단지 데이터의 의도된 용도가 무엇인지만을 알면 된다.

전술한 예는 또한 클래스 타입들이 상이한 계층들에 어떻게 배열될 수 있는지를 설명한다. 특히, 전술한 예는 주소 베이스 클래스, 및 그 주소 베이스 클래 스에 대응하는 US 주소 클래스를 식별한다. 이것은, 예를 들어, 상이한 계층 분류에 대응하는 관련 데이터를 저장할 수 있는 개별 테이블 또는 기타 데이터베이스 구조를 생성하는 데에 유용할 수 있다.

여기에는 주소 클래스에 대한 테이블들이 도시되어 있지 않지만, 주, 거리 이름, 번지 등과 같이, 여러 상이한 유형의 주소에 공통적인 일반 주소 정보를 저장하기 위한 상이한 열들을 포함할, 주소에 대한 일반 베이스 클래스 테이블이 어떻게 생성될 수 있는지 상상할 수 있다. 그 후 모든 주소에 대해 관련되지는 않을 수 있는 더욱 특정한 주소를 포함하는 특수화된 테이블 또는 기타 구조에 서브클래스가 저장될 수 있다. 예를 들어, 세계적인 규모의 디렉토리 어플리케이션에서, 모든 국가들이 우편 번호를 포함하지는 않을 것이다. 마찬가지로, 미국에서의 주소는 외국 주소에 관련된 주소 코드 및 기타 정보를 포함할 수 없다. 그러한 상황에서, 상이한 지역 주소 테이블 각각은 베이스 클래스 테이블로부터의 일반적인 주소 정보에 대한 신속한 액세스를 여전히 가능하게 하면서, 모든 주소 객체에 대해 관련되지는 않는 특수화된 정보를 포함할 수 있다.

상호 참조에 관한 이전 예에서와 같이, 베이스 클래스 테이블(예를 들어, 베이스 주소 클래스 테이블)이 서브클래스 테이블(예를 들어, 지역 클래스 테이블)과 상호-참조될 수 있다는 점 또한 잘 알 것이다. 이 기술은 클래스와 서브클래스 테이블들 사이의 다양한 깊이의 계층 레벨을 생성하기 위해 이용될 수 있다.

이제 본 발명을 구현하기 위한 한 방법을 보여주는 도 3에 도시된 흐름도(300)에 주목할 것이다. 도시된 바와 같이, 방법은 저장될 데이터를 식별하는 단 계(310)를 포함한다. 이러한 점에서, 데이터라는 용어는 저장될 예정인 데이터 타입을 일컫는다. 이러한 식별은 컴퓨터 판독가능 매체에 유지되는 지속형 저장 모듈(도시되지 않음)에 데이터 타입을 식별하는 코드가 제공되는 경우에 발생할 수 있다.

다음으로, 데이터를 저장하기 위해 어떤 데이터 베이스 스키마(예를 들어, 데이터베이스 구조)가 사용되어야 하는지에 관한 결정이 행해진다. 이러한 결정은 상기 기술된 바와 같이 데이터 타입에 관련된 장식의 식별에 응답하여 자동으로 행해진다. 특히, 어떤 데이터 구조가 생성되어야 하는지 또는 그것들이 데이터베이스 저장 툴을 사용하여 어떻게 선택되거나 생성되어야 하는지에 관한 어떠한 특별한 이해도 프로그래머가 반드시 가질 필요는 없다. 대신에, 본 발명은 코드에 정의된 데이터 타입에 관련된 장식에 기초하여 데이터 구조의 자동적인 생성을 제공하고, 장식은 데이터의 의도된 용도 또는 액세스를 반영한다.

다음으로, 적합한 데이터베이스 구조가 존재하는지가 결정된다(330). 만약 존재하지 않는다면, 데이터베이스 구조가 생성된다(340). 예를 들어, 도 1 및 2는 생성될 수 있는 테이블의 특정 실시예를 도시한다. 그러나, 이 테이블들이 본 발명의 범위를 제한하는 것으로 여겨져서는 안 된다. 데이터베이스 구조의 생성(340)은, 도 1 및 2를 참조하여 상기에 기술되고 도시된 바와 같이, 데이터베이스 테이블을 생성하는 단계, 및 코드에서 대응하는 필드들에 의해 식별된 적어도 몇몇의 열로 테이블을 채우는 단계를 포함할 수 있다.

데이터베이스 구조를 생성하는 단계(340)는 또한 데이터 타입에 대응하는 다 수의 테이블의 생성을 포함할 수 있다. 생성될 수 있는 테이블은, 예를 들어, 코드에서 식별된 타입을 정의하고, 그에 대응하는 데이터베이스 테이블 각각을 식별하는 타입 테이블을 포함할 수 있다. 이 테이블 및 기타 유사한 테이블들은 하기에 보다 상세히 기술된다. 해당 데이터 타입을 저장하기에 적합한 데이터베이스 구조가 존재하지 않는다고 결정되면, 베이스 클래스 및 서브-클래스 테이블이 몇 개라도 생성될 수 있다.

도 3에 나타낸 방법은, 적합한 데이터베이스 구조(예를 들어, 테이블)가 생성된 후, 저장될 데이터 객체를 획득하는 단계(350)를 포함한다. 이것은, 예를 들어, 단일 인스턴스 동안 또는 소정 기간에 걸쳐, 임의의 수의 연결되거나 분리된 데이터베이스 및 어플리케이션으로부터 수행될 수 있다. 데이터 객체가 획득되면(350), 그 데이터 객체가 이미 저장되어 있는지가 결정된다(360). 이것은 특히 대응하는 필드들 중 하나가 [CLSIIdentity] 속성으로 장식된 때에, 예를 들어 적합한 테이블을 검사함으로써 수행될 수 있으며, 이 속성은 그 속성 필드에 대해 동일한 값을 갖지 않는 어떠한 두 엔트리도 동일하지 않을 것이라는 것을 나타낸다. 따라서, 만약 또다른 엔트리가 대응하는 장식 필드에 동일한 값을 가지면, 그 엔트리는 이미 수신되었다고 결정될 수 있으며, 그 새로운 데이터는 이미 수신된 것에 대한 중복이거나 갱신이다. 데이터 객체의 중복 엔트리를 감소시킴으로써, 저장 용량 및 질의 프로세싱 요구사항이 최소화될 수 있다.

일 실시예에서, 필드가 기본 키의 일부인지를 나타내기 위하여, 식별자 속성이 필드들에 적용된다. 이 실시예에 따르면, 지속형 클래스들의 계층의 루트를 형 성하는 클래스에 있는 적어도 하나의 필드에 식별자 속성이 적용되어, 그 적어도 하나의 필드가 상기 기술된 바와 같이 중복 저장을 방지하기 위하여 사용될 수 있는 기본 키를 식별하는 데에 사용될 수 있게 한다.

예시된 방법의 다음 엘리먼트는 데이터 객체가 아직 기록되지 않았다면 그 데이터 객체를 기록하는 단계(370)를 포함한다. 이것은, 데이터 객체의 임의의 부분을 상기에 설명된 데이터베이스 테이블들 중 하나 이상에 기록하거나, 임의의 기타 방식으로 기록하는 단계를 포함할 수 있다. 이것은 데이터베이스 테이블에 데이터 객체의 파생물을 기록하는 단계도 포함할 수 있다. 이것은 또한 또다른 위치에 저장된 실제 데이터를 포인팅하는 데이터베이스 테이블에 대한 포인터를 기록하는 단계를 포함할 수 있다.

기타 실시예에서, 본 발명의 방법은 또한 이미 데이터베이스 구조에 저장되어 있는 것으로 발견된 데이터를 수정하는 단계(380)를 포함할 수 있다. 예를 들어, 만약 데이터가 저장된 마지막 시각 이후 데이터에 갱신이 행해졌다면, 데이터를 갱신하는 것이 유용할 수 있다. 갱신된 데이터가 예전 데이터와 별도로 독립적으로 저장되어 귀중한 저장 공간을 사용하는 것을 방지하기 위하여, 데이터가 동일한 것이며 나 덮어쓰여야 하는 것인지를 결정하기 위해 기본 키가 사용될 수 있다. 그렇지 않으면, 레코드는 나중에 객체로 다시 리트리브(retrieve)될 때 오래된 정보를 산출할 것이다. 중복 저장을 방지하기 위한 고유 키의 사용은 또한 데이터에 대한 요청에 응답하여 동일한 엔터티에 대해 상이한 집합의 정보를 산출하는 것을 방지하기 위하여 유익하다.

전술한 예들은 데이터베이스 테이블을 포함하는 데이터베이스 구조를 참조하여 제공되지만, 본 발명의 범위는 또한 데이터베이스 구조가 XML 파일 또는 기타 저장 구조를 포함하는 실시예와 같은 기타 실시예들에 확장된다는 점을 잘 알 것이다.

본 발명의 범위는 또한 데이터 스토어가 어레이 또는 딕셔너리(dictionary)인 실시예들에 확장된다. 예를 들어, 어레이는, 어레이 내의 차원의 수 및 차원의 순위에 대응하는 상이한 열들에 대한 두 개의 부가적인 데이터 엘리먼트 또는 집합을 제공함으로써 상기 기술된 컬렉션과 마찬가지로 구성될 수 있다.

요약하면, 상기 기술된 방법을 구현하기 위한 컴퓨터-실행가능 명령어들을 갖는 하나 이상의 컴퓨터 판독가능 매체로부터 저장 및 구현될 수 있는 본 발명은, 본 명세서에서 때때로 지속형 저장 또는 .NET 데이터 타입 및 인스턴스에 대한 지속형 저장으로 언급된다. 기술된 바와 같이, 지속형 저장은 데이터 구조들을 데이터베이스 내에 직렬화하기 위한 일반적인 메커니즘을 제공하고, 이에 의해 임의의 데이터 구조를 저장하고 요구 시에 그것들을 검색하기 위한 일반적인 방식을 필요로 하는 많은 서비스에 해결책을 제공한다.

지속형 저장은 CLR(Common Language Runtime)에 의해 제공된 기능성에 기초하지만, 스토어 아래의 상이한 데이터 소스들에 플러그인하는 것이 당연히 가능할 것이다. 또한, Java에 기초한 것들과 같은 대안적인 데이터 모델 또한 지원될 수 있으므로 .NET 데이터 타입에 기초하여 본 발명에 의해 사용된 데이터 모델이 본 발명의 범위를 제한하는 것으로 여겨져서는 안 된다.

이제, 본 발명에 관한 몇가지 흥미있는 변형 및 부가적인 세부사항이 아래의 설명에서 제공될 것이다.

처음에, 지속형 저장 프레임워크는 다음 엘리먼트들로 구성되는 것으로 기술될 수 있다. 첫번째는, 데이터 구조를 데이터 소스에 직렬화(serialize) 또는 역직렬화(deserialize)하는 기본 기능을 제공하는 ObjectStore이다. ObjectStore는 동작할 문맥을 수락할 수 있다. ObjectStore의 파생된 형태는 ObjectStore에 관련된 데이터 소스가 SQL 데이터베이스 또는 XML 파일인 특정 구현을 제공한다. 레코드 id, 스토어 문맥 등에 대한 특정 Store 구현에 관련된 클래스도 정의된다. 직렬화 속성 또한 적용된다. 본 발명에 기술된 바와 같이, 서비스 개발자가 필드에 대한 소정 부가적인 정보를 지정할 수 있도록 소수의 커스텀 속성이 정의된다. StoreService는 기초를 이루는 데이터베이스에 객체들을 유지하기 위하여 단일 접촉 포인트를 클라이언트에게 제공하는 ServiceBus 서비스이다.

프레임워크는 한 그래프 또는 컬렉션에서의 동일한 객체에 대한 다수의 참조가 단 한번 저장된다는 것을 보장한다. 다수의 그래프에서의 동일한 객체에 대한 참조도 스토어 내의 동일한 레코드에 귀착해야 한다. 이것을 보장하기 위하여, 클래스는 자신의 고유 id를 구성하는 필드들을 명기할 것을 필요로 한다.

역직렬화가 발생하고, 저장된 레코드로부터 객체 그래프 또는 컬렉션이 형성될 때, 모든 객체는 단 한번 생성되어야 한다. 그러나, 객체 참조들이 동일한 문맥에 속하는 것으로 명기되지 않으면, 그 객체 참조들이 다수의 역직렬화 호출에 걸쳐 동일한 객체에 귀착할 필요는 없다.

이제, 저장 및 검색 요청을 프로세싱하는 컴포넌트인 ObjectStore에 특히 주목한다. ObjectStore에 대응하는 예시적인 메소드 및 코드가 이제 제공될 것이다.

Constructor: ObjectStore는 저장 메커니즘의 시작 포인트이다. 검색 및 저장을 위한 스테이지를 설정하기 위해, 선택적인 StoreContext 파라미터가 사용된다. 만약 어떠한 문맥도 제공되지 않으면, StoreContext는 디폴트 값으로 초기화된다.

Write: 이 메소드는 호출자가 객체 o를 저장하도록 허용한다. 객체 o는 프리미티브 타입, 구조체, 클래스 또는 컬렉션일 수 있다.

객체가 저장되었으면, Write 메소드는 고유한 RecordID를 리턴한다. 그렇지 않으면, 널(null)을 리턴하거나 StoreException 예외를 발생시킨다.

Read: 이 메소드는 RecordID와 타입이 주어진 때에 그에 해당하는 객체를 형성한다. 과부하된 버전(overloaded version)은 명기된 기준에 기초하여 객체들의 컬렉션을 리턴한다.

Delete: 이 메소드는 RecordID와 타입이 주어진 때에 그에 해당하는 객체를 삭제한다. 과부하된 버전은 명기된 기준에 기초하여 객체를 삭제한다. 파라미터는 다른 객체들에 대한 참조가 재귀적으로 추적되어야 하는지를 나타낸다. 외부 객체의 삭제의 결과로서 내부 객체에 대한 ref 카운트가 0으로 되면, 연쇄적인 삭제 동작이 발생할 수 있다.

타입 설명:

이제, 직렬화 및 참조용 동작속성을 포함하는 커스텀 속성의 소정 예들을 주목한다. 소정 속성들에 대응하는 예시적인 코드가 이제 제공될 것이다.

직렬화 속성(Serialization Attributes)

SerializableAttribute 및 NonSerializableAttribute는 한 타입의 인스턴스들이 직렬화될 수 있는지 아닌지를 나타낸다. 저장 가능성과 직렬화 가능성은 관련된 개념으로 취급된다. 저장 가능성은 파일 또는 데이터 스토어에 직렬화하는 것으로서 취급된다.

CLSIIdentityAttribute

상기 언급된 바와 같이, CLSIIdentityAttribute는 필드가 기본 키의 일부인지를 나타내기 위하여 필드에 적용되는 커스텀 속성이다. CLSIIdentityAttribute는 지속형 클래스들의 계층의 루트를 형성하는 클래스 내의 적어도 하나의 필드에 적용되어야 한다.

ReferentialActionAttribute

ReferentialActionAttribute는 참조된 객체가 삭제되면 행해야 할 동작을 나타내기 위하여 참조 필드에 대해 적용되는 커스텀 속성이다.

기타 속성들은 도 1과 2 및 대응하는 예들을 참조하여 상기에 기술되었다.

이제, SQL 데이터베이스에의 저장 및 검색 요청을 프로세싱하는 컴포넌트인 SqlStore에 주목할 것이다. SqlStore는 데이터베이스 연결을 수립하고, Read 및 Write 호출을 DataAdapter 등이 이해할 수 있는 것으로 번역한다. SqlStore에 대응하는 예시적인 메소드 및 코드가 이제 제공될 것이다.

Constructor: SqlStore는 SQL 저장 메커니즘의 시작 포인트이다. 선택적인 StoreContext 파라미터는 검색 및 저장을 위한 스테이지를 설정하기 위해 사용된다. 만약 어떠한 문맥도 제공되지 않으면, StoreContext는 디폴트 값으로 초기화된다.

a) _database 이름: "ServiceBus"로 설정

b) _varMaxLength: 1024로 설정

Write: 이 메소드는 호출자가 객체 o를 저장하도록 허용한다. 객체 o는 프리미티브 타입, 구조체, 클래스 또는 컬렉션일 수 있다.

객체가 저장되어 있거나 이미 존재하는 것이면, write 메소드는 고유한 SqlRecordID를 리턴한다. 그렇지 않으면, 널을 리턴하거나 StoreException 예외를 발생시킨다.

Read: 이 메소드는 RecordID가 주어진 때, 객체를 형성한다.

VarMaxLength: 이 속성은 varchar 및 varbinary SQL 타입을 정의하면서 사용될 최대 길이를 제공한다. 디폴트 값은 1024이다.

타입 설명:

본 발명은 여러 상이한 환경에서 상이한 관계 데이터베이스를 이용하여 실행될 수 있지만, 다음 예는 SQL 데이터베이스에서 객체를 저장하는 것에 수반된 동작 들 중 일부를 설명한다. 특히, 객체를 저장하는 것은 SQL 데이터베이스에서 다음 동작들을 수반한다.

a) 테이블 생성: 필요하다면, 객체 타입에 대응하는 SQL 테이블이 생성된다. 만약 그렇지 않다면, 객체가 저장될 SQL 테이블이 식별된다.

b) 객체에 대응하는 SQL 테이블이 가용한 경우, 객체가 이미 테이블에 저장되었는지를 검사하기 위하여, 기본 키를 구성하는 필드들이 사용된다. 만약 행이 이미 존재하면, 그것은 현재의 객체를 가지고 갱신되고, 그렇지 않으면 새로운 레코드가 생성된다.

c) 직렬화가능한 객체 인스턴스의 필드들이 저장된다. 객체의 멤버 및 재귀적으로 그들의 멤버들의 타입에 기초하여, 필요하다면 더 많은 SQL 테이블이 생성된다.

생성될 수 있는 상이한 테이블들의 예가 이제 제공될 것이다.

ObjectTypeTable

ObjectTypeTable은 CLR 클래스/구조의 XmlTypeName을 데이터 소스 테이블의 이름에 매핑하는 SQL 테이블이다. 저장 프로세스 동안 생성되는 모든 SQL 테이블에 대하여, ObjectTypeTable에 엔트리가 생성된다.

objectTypeID: 발견된 모든 타입에 주어진 고유한 id.

objectTypeName: 검색을 위해 사용될 수 있는 정규화된(fully qualified) 타입 이름. 버전들 간에서 필드 변경이 없었던 타입이 동일한 데이터 타입 이름에 귀착할 수 있도록, AssemblyQualifiedName 대신 XmlTypeName이 사용될 수 있다.

sqlTableName: CLR 타입에 대응하는 테이블의 이름을 제공한다.

rootTypeID: 지속형 클래스 계층의 루트를 제공한다. 이 루트 클래스는 사용자에 의해 지정된 기본 키를 가져야 한다. 고유 id는 이 루트 테이블 내의 모든 새로운 행에 대해 생성되고, 클래스 계층 체인을 따라 모든 파생된 클래스 테이블에서 재사용될 것이다.

baseTypeID: 베이스 클래스 id를 제공한다. 지속형 클래스 계층의 루트에 대해 널일 것이다.

lastObjectID: 이 CLR 타입에 대응하는 SQL 테이블에 추가된 마지막 행의 SqlRecordID를 제공한다.

ObjectBaseTypeTable

ObjectBaseTypeTable은 클래스들의 베이스 클래스 관계를 유지하는 SQL 테이블이다. 저장 프로세스 동안 생성되는 모든 SQL 테이블에 대해, 하나 이상의 엔트리가 ObjectBaseTypeTable내에 생성된다. 만약 타입 A가 B의 베이스 클래스라면, 엔트리는 소스로서 A를 갖는 행을 포함한다.

이 테이블은 질의 동안 유용하다.

srcObjectTypeID: 관계의 소스인 타입.

destObjectTypeID: 관계의 대상인 타입.

relationship: 소스와 대상 사이의 관계.

ObjectArrayTable

ObjectArrayTable은 임의의 어레이를 구성하는 엘리먼트들을 포함하는 SQL 테이블이다. 모든 어레이 인스턴스의 엘리먼트들이 여기에 저장된다.

objCollectionID: 발견된 모든 어레이 인스턴스에 주어진 고유 id.

elemIndex: 어레이 내의 엘리먼트의 인덱스.

elemObjID: 엘리먼트 객체의 레코드 id.

elemTypeID: 엘리먼트 객체의 타입을 제공한다. 이것은 엘리먼트가 저장되는 테이블을 찾는 것을 도울 것이다.

ObjectDictionaryTable

ObjectDictionaryTable은 임의의 딕셔너리를 구성하는 엘리먼트들을 포함하는 SQL 테이블이다. 모든 딕셔너리 인스턴스의 엘리먼트들이 여기에 저장된다. 실제 키 및 엘리먼트 객체들이 그들의 CLR 타입에 대응하는 SQL 테이블에 저장된다는 점을 유의해야 한다.

objCollectionID: 발견된 모든 딕셔너리 인스턴스에 주어진 고유 id.

elemKeyID: 키 객체의 레코드 id.

elemObjID: 엘리먼트 객체의 레코드 id.

elemTypeID: 엘리먼트 객체의 타입을 제공한다. 이것은 엘리먼트가 저장되는 테이블을 찾는 것을 돕는다.

이제 CLR 타입의 매핑에 다시 주목할 것이다. 특히, 각 클래스 타입은 개별적인 SQL 테이블로서 저장된다. 클래스의 한 인스턴스에 있는 각 필드의 값은 SQL 테이블에 열 값으로서 저장된다.

객체 테이블은 클래스 또는 구조체 타입의 등가물이며, 해당 타입의 객체를 처음 만난 때에, 진행 중에 생성된다. 객체의 인스턴스 타입이 이용가능할 때는 언제나 그 인스턴스 타입이 사용되고, 그렇지 않으면 객체의 선언된 타입이 사용된다. 예를 들어, 만약 객체가 널이면, 선언된 타입이 사용된다.

클래스 서브타입은 파생된 클래스의 필드들을 포함하는 SQL 테이블내로 번역되며, SQL 레코드를 참조할 별도의 SqlRecordId 열은 루트 클래스 인스턴스 값에 대응한다. 지속형 클래스 체인은 ObjectTypeTable에 저장된다.

루트 테이블은 실제 인스턴스 타입을 제공하는 별도의 열을 포함한다. 루트 객체 테이블은 또한 ref 카운트를 위한 두 개의 열을 포함할 것이다. 이들은 삭제동안 유용할 것이고, 순환 그래프 역시 다룰 것이다. 하나의 ref 카운트는 객체가 객체 그래프의 루트로서 넘겨받은 것인지 추적하고(이 카운트는 단지 0 또는 1 두 개의 값만을 가짐), 또다른 ref 카운트는 이 객체를 참조하는 객체들의 총 수를 보유한다. 두 ref 카운트 모두 0이 되는 경우에만 행이 삭제될 것이다.

테이블의 기본 키 타입은 객체 타입의 커스텀 속성으로부터 결정된다. 기본 키를 명기하는 커스텀 속성은 해당 타입의 하나 이상의 필드에 대해 설정될 수 있다. 루트 지속형 클래스는 이 속성을 갖는 적어도 하나의 필드를 포함하여야 한다. SqlStore는 또한 자동으로 생성되는 고유 id를 포함할 테이블 정의에 SqlRecordId 열을 추가한다. 이 id는 SQL 테이블 내에서 고유한 64-비트 숫자이며, 대체 키(alternate key)로서 정의될 것이다. 기본 키가 명시적으로 명기된 경우에도, SqlRecordId는 이 객체를 참조하는 내부 객체에서 항상 외래 키로서 사용될 것이다.

기본 키를 구성하는 모든 필드는 루트 지속형 클래스의 직렬화가능한 멤버이 어야 한다. 그렇지 않으면, 객체가 이미 저장되었는지를 검사하기 위하여, 기본 키 내의 참조 필드들의 SqlRecordId가 먼저 획득되어야 한다. 참조 필드 자체가 자신의 기본 키 내에서 참조 필드를 포함할 수 있기 때문에, 이것은 재귀적 프로세스임을 유의해야 한다. 다음 단락은 이러한 예를 제공한다.

여기서, 객체 "a"가 이미 보유되어 있는지를 알기 위하여, a.id에 대응하는 SqlRecordId에 대해 MediaId 테이블을 질의할 필요가 있다. 이것을 가지면, SqlRecordId 및 위치 값에 의하여 주어진 기본 키에 대해 Media 테이블에 질의할 수 있다.

어떠한 필드도 가지지 않는 클래스는 SqlRecordId인 단일 열을 갖는 SQL테이블로 번역된다. 이하에는, 이에 관한 예들이 제공될 것이다.

예를 들어,

다음 SQL 테이블들이 생성된다.

조건:

b의 objID는 1이고, c의 objID는 2라고 가정한다. 그러면 id 1을 갖는 행이 BTABLE에 나타날 것이고, 반면 id 2를 갖는 행은 BTABLE 및 CTABLE에 나타날 것이다.

클래스 타입으로 타입화된 클래스 멤버는 인클로징 클래스(enclosing class) 에 대해 생성된 SQL 테이블에서 SqlRecordId 열로 번역될 것이다. 외래 키 제약(foreign key constraint)이 이 열에 부과된다. 내부 클래스 타입의 서브타입들의 인스턴스들이 인클로징 클래스 인스턴스에서도 존재할 수 있더라도, 루트 클래스 레벨에서는 모든 id가 고유하기 때문에, 이것이 가능하다. 참조된 행의 refCount 및 rootRefCount 열이 적절히 유지된다.

클래스 멤버가 한 클래스 타입에 속하고 기본 키의 일부가 아니라면, 그 클래스 멤버는 널 값을 가질 수 있다(nullable). 프리미티브 타입 및 구조체에 속하는 멤버들은 널 값을 가질 수 없다(non-nullable). SQL 테이블 정의에서, 널 값을 가질 수 있는 필드들은 nullable로서 명기된다.

클래스 인스턴스 A 및 B가 객체 그래프에서 서로에 대한 참조를 포함하는 경우, A 및 B는 단 한번 저장된다. A 및 B는 서로의 SqlRecordId를 포함할 것이다. 예는 다음과 같다.

다음 SQL 테이블이 생성된다.

일 실시예에서, 구조체 타입은 필드들을 갖는 개별적인 테이블로서 번역된다. CLR 구조체가 값(value) 타입이지만, 제한된 구조에 대한 다수의 참조의 경우를 최적화하기 위하여 독립적인 테이블이 생성된다. 구조체는 상속성 체인을 갖지 않는 클래스와 동일하게 취급된다.

구조체 인스턴스 내의 각 필드의 값은 테이블 내에 열 값으로서 저장된다. 구조체 타입을 갖는 클래스 또는 구조체 멤버는 클래스에 대해 생성된 SQL 테이블에서 SqlRecordId 열로 번역될 것이다.

두번째 실시예에서, 구조체 타입으로서 타입화된 클래스 멤버의 멤버들은 인클로징 클래스에 대해 생성된 동일 테이블에 저장되며, 구조체 타입의 멤버들에 대응하는 열 이름은 인클로징 클래스에서 구조체 타입으로서 타입화된 클래스 멤버 이름을 접두사로 갖는다.

세번째 실시예에서, 구조체 타입으로서 타입화된 클래스 멤버의 멤버들은 인클로징 클래스에 대해 생성된 테이블에서 사용자 정의 타입(UDT)으로서 저장된다.

프리미티브 타입을 갖는 객체는 프리미티브 타입 테이블로서 번역된다. 프 리미티브 타입 테이블은 두 개의 열 - SqlRecordId 열, 및 프리미티브 타입에 대한 열 - 을 포함한다. 일 실시예에 따르면, 프리미티브 타입을 갖는 객체들의 선택적인 검색 및 삭제는 지원되지 않는다.

프리미티브 타입을 갖는 클래스 또는 구조체 멤버는 다음과 같이 SQL 테이블의 열로서 번역된다. 열의 값은 프리미티브 타입의 값이다.

어레이는 고유한 SqlRecordId를 발행받고, 그 엘리먼트에 대응하는 다수의 행으로서 ObjectArrayTable에 저장된다. 이 테이블의 각 행은 어레이 인스턴스의 SqlRecordId 및 엘리먼트 인덱스를 포함할 것이다. 실제 엘리먼트들은 그들의 인스턴스 타입에 대응하는 테이블에 저장된다. 어레이가 클래스의 멤버라면, 어레이의 SqlRecordId는 인클로징 클래스에 저장된다.

ArrayList, Queue: 이들은 어레이와 동일하게 취급되고, ObjectArrayTable에 저장된다.

HashTable: 이들은 어레이가 유사하게 취급되지만, ObjectDictionaryTable에 저장된다. 이 테이블의 각 행은 엘리먼트 인스턴스의 SqlRecordId 및 엘리먼트 키를 포함할 것이다.

객체 검색 및 질의(OBJECT RETRIEVAL AND QUERYING)

객체는 두 가지 방식 - (1) 객체의 SqlRecordID 및 타입을 사용하는 방식 및 (2) 선택 기준 및 타입을 사용하는 방식 - 으로 검색될 수 있다. 타입은 루트로부터 객체의 실제 타입까지 퍼시스턴스 클래스 계층에 있는 임의의 타입일 수 있다. 만약 SqlRecordID가 명기되고 타입이 컬렉션이 아니면, 그것을 검색하기 위하여 다음 단계들이 수행될 수 있다.

a) ObjectTypeTable을 찾고 타입에 대한 루트 테이블 이름을 획득한다.

b) 객체의 실제 타입을 획득한다.

c) ObjectTypeTable로부터 인스턴스에 대한 테이블 이름을 획득한다.

d) SQL 테이블로부터 행을 획득한다.

e) 테이블 이름으로부터 CLR 타입의 정규화된 이름을 획득한다.

f) 디폴트 생성자를 사용하여 획득된 CLR 타입의 객체를 생성한다(지속가능한 객체가 디폴트 생성자를 가질 것으로 기대됨).

g) CLR 타입이 프리미티브 타입이라면, 직접 값을 할당한다.

h) 만약 CLR 타입이 클래스나 구조체라면, 객체의 필드들을 행의 필드들로 할당한다. 프리미티브 필드들에 대해 직접 할당하고, 기타 필드들에 대해 재귀적으로 레코드 id를 따르고, 참조된 객체를 검색한다. 참조된 객체는 자체가 클래스, 구조체 또는 컬렉션일 수 있다는 점을 유의해야 한다.

i) 객체 그래프를 역직렬화하는 동안 객체는 단 한번 생성된다는 것을 계속하여 추적한다.

만약 SqlRecordID가 명기되고 타입이 컬렉션이면, 그것을 검색하기 위하여 다음 단계들이 구현될 수 있다.

a) 컬렉션 id로서 명기된 id를 갖는 관련 컬렉션 테이블에 있는 행의 수를 획득한다. 존재하는 행만큼의 엘리먼트를 컬렉션에 생성한다.

b) 각 엘리먼트에 대한 객체 검색 규칙을 재귀적으로 따른다.

질의가 제공된 객체를 검색하는 것은 훨씬 복잡할 수 있고, 다음을 포함할 수 있다.

a) 질의 번역 규칙을 따르고, Query를 SQL로 번역한다.

b) 질의를 실행하고 타입의 SQL 테이블에서 매칭하는 행을 획득한다.

c) 각 행에 대한 객체 검색 규칙을 따른다.

객체는 두 가지 방식 - (1) 객체의 SqlRecordID 및 타입을 사용하는 방식 및 (2) 선택 기준 및 타입을 사용하는 방식 - 으로 삭제될 수 있다. 타입은 루트로부터 객체의 실제 타입까지 퍼시스턴스 클래스 계층에 있는 임의의 타입일 수 있다. 만약 SqlRecordID가 명기되고 타입이 컬렉션이 아니면, 그것을 삭제하기 위하여 다음 단계들이 수행될 수 있다.

a) 객체 타입으로부터 루트 테이블 id를 획득한다.

b) 루트 테이블에서 행을 획득한다. 루트 ref 카운트를 감소시킨다.

c) 실제 객체 타입을 획득한다. 계층 체인을 따르고, 객체에 대응하는 각 행의 필드들을 통과하며, 프리미티브가 아닌 필드들의 레코드 id를 획득한다.

d) 프리미티브가 아닌 필드들 각각에 대하여, 참조된 테이블 id를 획득한다. 참조된 행의 도달가능한 ref 카운트를 감소시킨다. 재귀적으로, 내부의 프리미티브가 아닌 필드들을 가로지르고, 동일한 규칙을 적용한다. 만약 두 ref 카운트 모두 0으로 떨어지면 참조된 행을 삭제한다.

e) 루트 ref 카운트와 도달가능한 ref 카운트 둘 모두 0이면 본래의 행을 삭제한다.

단계 c, d는 recurse 파라미터가 true로 설정된 경우에만 행해져야 한다. 만약 SqlRecordID가 명기되고 타입이 컬렉션이면, 그것을 삭제하기 위하여 다음 단계들이 구현될 수 있다.

a) 명기된 id를 컬렉션 id로서 갖는 관련 컬렉션 테이블에서 행을 획득한다.

b) 각 엘리먼트에 대해 객체 삭제 규칙을 재귀적으로 따른다.

질의가 주어진 객체를 삭제하는 것은 훨씬 복잡할 수 있고, 다음을 수반할 수 있다.

a) 질의 번역 규칙을 따르고, Query를 SQL로 번역한다.

b) 질의를 실행하고, 타입의 SQL 테이블에서 매칭하는 행을 획득한다.

c) 각 행에 대해 객체 삭제 규칙을 따른다.

전술한 것에 기초하여, 상기 기술된 데이터베이스 구조 및 테이블에 저장된 데이터에 대해 다양한 타입의 질의가 또한 수행될 수 있다는 점을 잘 알 것이다. 도 1 및 2를 참조하여 기술된 예에 대해 수행될 수 있는 질의들의 제한을 가하지 않는 소정 예들이 이제 제공될 것이다. 예를 들어, 우편 번호 98074에 살고 있는 고객의 상품 주문을 검색하기 위하여, XPATH 질의가 /Customers[typeof(address) == USAddress && address.zip == 98074]/orders와 같은 것일 수 있다. 마찬가지로, 적어도 하나의 두드러진 상품 주문을 한 고객의 주소를 검색하기 위하여, XPATH 질의는 /Customers[Count(orders)>0]/address일 것이다. 유사하게, 적어도 하나의 노래를 갖는 "Sting" 앨범을 검색하기 위하여, XPATH 질의는 /Albums[Exists(artists, name == "Sting") && count(songs) > 0]와 같은 것일 것이다. 제목이 Groovy인 앨범의 노래들을 검색하기 위하여, XPATH 질의는 /Albums[title == "Groovy"]/songs와 같은 것일 것이다. 마지막으로, 제목이 "Whenever"인 노래를 포함하는 앨범을 검색하기 위하여, XPATH 질의는 /Songs[title == "Whenever"]/album과 같은 것일 것이다.

본 발명에서 제공된 전술한 구현 세부사항 및 예에도 불구하고, 본 발명의 범위는 저장될 클래스 및 데이터 타입의 객체 및 필드에 관련되는 속성 및 기타 장식에 응답하여 테이블 또는 기타 데이터 구조가 생성되는 임의의 방법, 시스템 또는 컴퓨터 프로그램 제품에 널리 확장된다는 점을 잘 알 것이다. 데이터를 저장하기 위한 데이터베이스 메커니즘을 생성하기 위한 그러한 방법은 데이터베이스에 관한 프로그래머의 전문성에 의존하는 것이 아니라, 단지 데이터에 대한 의도된 용도 에 대한 지식에 의존한다. 이것은 데이터베이스가 어떻게 구성되기를 원하는지를 프로그래머가 이해할 것을 요구하는 Access 및 기타 데이터베이스 툴과 같은 종래의 시스템에 대한 개선을 나타낸다.

본 발명은 또한 데이터베이스 메커니즘이 여러 상이한 데이터 포맷 및 관계 데이터베이스 시스템과 확장가능 및 상호동작 가능하도록 한다. 따라서, 본 발명이 다양한 컴퓨팅 환경에서 실행될 수 있다는 점을 잘 알 것이다. 본 발명이 실행될 수 있는 적합한 컴퓨팅 환경의 한 예가 이제 후술된다.

컴퓨팅 환경

상기 기술된 방법은 개인용 컴퓨터, 포켓형 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 또는 프로그래밍가능 가전기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다양한 구성을 갖는 임의의 수의 컴퓨팅 모듈 및 시스템 및 네트워크 컴퓨팅 환경의 사용으로 수행될 수 있다. 본 발명은 또한 통신 네트워크를 통해 연결되는(하드웨어 링크, 무선 링크에 의해서든지 하드웨어 또는 무선 링크의 조합에 의해서든지) 로컬 및 원격 프로세싱 장치에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서도 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 둘 모두에 위치될 수 있다.

도 4를 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 프로세싱 유닛(421), 시스템 메모리(422), 및 시스템 메모리(422)를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(421)에 연결하는 시스템 버스(423)를 포함하는 전형적인 컴퓨터(420)의 형태로 범용 컴퓨팅 장치를 포함한다. 시스템 버스(423)는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 다양한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스를 포함하는 여러 유형의 버스 구조 중 임의의 것일 수 있다. 시스템 메모리는 ROM(424) 및 RAM(425)을 포함한다. 시작할 때 등에 컴퓨터(420) 내의 구성요소들 사이의 정보 전달을 돕는 기본 루틴을 포함하는 기본 입력/출력 시스템(BIOS)(426)은 ROM(424)에 저장될 수 있다.

컴퓨터(420)는 또한 자기 하드 디스크(439)에 판독 및 기입하기 위한 자기 하드 디스크 드라이브(427), 분리형 자기 디스크(429)에 판독 및 기입하기 위한 자기 디스크 드라이브(428), 및 CD-ROM, DVD-ROM, 또는 기타 광 매체와 같은 분리형 광 디스크(431)에 판독 및 기입하기 위한 광 디스크 드라이브(430)를 포함할 수 있다. 자기 하드 디스크 드라이브(427), 자기 디스크 드라이브(428) 및 광 디스크 드라이브(430)는 각각 하드 디스크 드라이브 인터페이스(432), 자기 디스크 드라이브-인터페이스(433) 및 광 드라이브 인터페이스(434)에 의해 시스템 버스(423)에 연결된다. 드라이브 및 관련 컴퓨터-판독가능 매체는 컴퓨터(420)에 컴퓨터-실행가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 비휘발성 저장을 제공한다. 본 발명에 기술된 예시적인 환경이 자기 하드 디스크(439), 분리형 자기 디스크(429) 및 분리형 광 디스크(431)를 이용하지만, 자기 카세트, 플래시 메모리 카드, DVD, 베르누이 카트리지, RAM, ROM 등을 포함하는, 데이터를 저장하기 위한 기타 유형의 컴퓨터 판독가능 매체가 사용될 수 있다.

운영 시스템(435), 하나 이상의 어플리케이션 프로그램(436), 기타 프로그램 모듈(437) 및 프로그램 데이터(438)를 포함하여, 하나 이상의 프로그램 모듈을 포 함하는 프로그램 코드 수단은 하드 디스크(439), 자기 디스크(429), 광 디스크(431), ROM(424) 또는 RAM(425)에 저장될 수 있다. 사용자는 키보드(440), 포인팅 장치(442), 또는 마이크, 조이 스틱, 게임 패드, 위성 디쉬, 스캐너 등과 같은 기타 입력 장치(도시되지 않음)를 통해 컴퓨터(420)에 명령어 및 정보를 입력할 수 있다. 이들 및 기타 입력 장치는 종종 시스템 버스(423)에 연결된 직렬 포트 인터페이스(446)를 통해 프로세싱 유닛(421)에 연결된다. 대안적으로, 입력 장치는 병렬 포트, 게임 포트 또는 USB와 같은 기타 인터페이스에 의해 연결될 수 있다. 모니터(447) 또는 또다른 디스플레이 장치 또한 비디오 어댑터(448)와 같은 인터페이스를 통해 시스템 버스(423)에 연결된다. 모니터 외에, 개인용 컴퓨터는 전형적으로 스피커 및 프린터와 같은 기타 주변 출력 장치(도시되지 않음)를 포함한다.

컴퓨터(420)는 원격 컴퓨터(449a 및 449b)와 같은 하나 이상의 원격 컴퓨터에의 논리적 연결을 사용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(449a 및 449b)는 각각 또다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스 또는 기타 공통 네트워크 노드일 수 있고, 도 4에는 메모리 저장 장치(450a 및 450b) 및 관련 어플리케이션 프로그램(436a 및 436b)만이 도시되었지만, 전형적으로 컴퓨터(420)에 관련되어 상기 기술된 구성요소들 중 다수 또는 모두를 포함한다. 도 4에 도시된 논리적 연결들은 근거리 통신망(LAN)(451) 및 광역 통신망(WAN)(452)을 포함하며, 제한을 가하지 않는 예로서 본 발명에 제공된다. 그러한 네트워크 환경은 사무실-규모 또는 기업-규모 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(420)는 네트워크 인터페이스 또는 어댑터(453)를 통해 LAN(451)에 연결된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(420)는 모뎀(454), 무선 링크, 또는 인터넷과 같은 WAN(452)을 거쳐 통신을 수립하기 위한 기타 수단을 포함할 수 있다. 내장 또는 외장일 수 있는 모뎀(454)은 직렬 포트 인터페이스(446)를 통해 시스템 버스(423)에 연결된다. 네트워크 환경에서, 컴퓨터(420)에 관련되어 도시된 프로그램 모듈 또는 그들의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 연결은 예시적이며, WAN(452)을 거쳐 통신을 수립하는 기타 수단들이 사용될 수 있음을 잘 알 것이다.

본 발명은 취지 또는 본질적인 특성을 벗어나지 않고서 기타 특정 형태로 구현될 수 있다. 기술된 실시예들은 모든 관점에서 제한적이지 않고 단지 예시적인 것으로 여겨져야 할 것이다. 그러므로, 본 발명의 범위는 전술한 설명에 의해서보다 첨부된 특허청구범위에 의해 나타내어진다. 특허청구범위의 등가의 의미 및 범위 내에 속하는 모든 변경이 본 발명의 범위 내에 포함되어야 한다.

기초를 이루는 데이터 스토어에 기본적으로 의존하지 않고 데이터 객체를 데이터베이스에 유지하기 위한 일반적인 메커니즘이 제공된다.

Claims (44)

1. 동적으로 데이터베이스 구조를 결정하고, 결정된 상기 데이터베이스 구조에 따라서 하나 이상의 데이터 타입의 객체들을 저장하기 위한 데이터 스토어를 생성하는 컴퓨터 구현 방법으로서,

   프로그래밍 코드의 세그먼트를 수신하는 단계 - 상기 프로그래밍 코드의 세그먼트는 상기 하나 이상의 데이터 타입들의 정의 및 상기 프로그래밍 코드 세그먼트에서 상기 하나 이상의 데이터 타입들 중 적어도 하나에 연관된 적어도 하나의 장식(adornment)을 포함하고, 상기 적어도 하나의 장식은 의도된 사용 또는 상기 연관된 데이터 타입의 액세스를 반영함 - ;

   상기 하나 이상의 데이터 타입들 중 적어도 하나와 연관되며 상기 프로그래밍 코드의 세그먼트 내에 정의된 적어도 하나의 장식을 식별하는 단계 - 상기 적어도 하나의 장식은, 계층의 루트를 형성하며 상기 데이터 타입이 상기 데이터베이스 내의 고유 키(unique key)를 표현해야만 한다는 것을 나타내는 클래스의 적어도 하나의 필드에 적용된 식별자 속성,

   상기 연관된 데이터 타입이 질의될 수 있어야 함을 나타내는 인덱스 속성,

   표시된 제2 데이터 타입과 상기 데이터 타입 간에 일대다(one-to-many) 관계가 존재함을 나타내는 백 포인터 속성(back pointer attribute), 및

   표시된 제2 데이터 타입과 상기 데이터 타입의 인스턴스들 간에 일대일 관계가 존재함을 나타내는 단일 참조용 속성(single reference attribute)을 포함함 - ;

   상기 하나 이상의 데이터 타입들의 각각의 정의와 상기 적어도 하나의 장식에 기초하여, 상기 하나 이상의 데이터 타입들에 대응하는 데이터를 저장하기 위해 사용될 데이터베이스 구조를 결정하는 단계 - 상기 데이터베이스 구조는 상기 프로그래밍 코드 세그먼트에 식별된 상기 하나 이상의 데이터 타입들 중 적어도 하나를 정의하는 타입 테이블을 포함함 - ;

   상기 결정된 데이터베이스 구조가 존재하는지를 결정하는 단계; 및

   상기 결정된 데이터베이스 구조에 대응하는 데이터 스토어를 생성하는 단계 - 상기 데이터 스토어는,

   데이터 구조를 데이터 소스에 직렬화(serialize) 또는 역직렬화(deserialize)하는 기본 기능을 제공하는 오브젝트스토어(ObjectStore), 및

   상기 데이터 스토어에 객체들을 유지하기 위하여 단일 접촉 포인트를 클라이언트에게 제공하는 서비스버스(ServiceBus) 서비스인 스토어서비스(StoreService)를 포함함 -

   를 포함하는 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
2. 제1항에 있어서, 상기 데이터 스토어는 상기 하나 이상의 데이터 타입들의 정의 및 장식 이외에 상기 데이터 스토어를 정의하는 특정 입력을 수신하지 않고서 생성되는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
3. 제1항에 있어서, 상기 데이터베이스 구조를 결정하는 단계는 상기 데이터 스토어 내에 저장된 데이터 타입 및 데이터에 관한 질의를 최적화할 구조를 결정하는 단계를 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
4. 제1항에 있어서, 상기 데이터 스토어를 생성하는 단계는 하나 이상의 데이터베이스 테이블을 생성하는 단계를 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
5. 제1항에 있어서, 상기 데이터 스토어를 생성하는 단계는 하나 이상의 XML 파일을 생성하는 단계를 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
6. 제1항에 있어서, 상기 프로그래밍 코드의 세그먼트에 정의된 모든 데이터 타입에 대해 상이한 데이터베이스 테이블이 생성되는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
7. 제1항에 있어서, 상기 적어도 하나의 장식은 상기 적어도 하나의 데이터 타입의 필드가 인덱스되어야 함을 명기하는 속성을 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
8. 제1항에 있어서, 상기 적어도 하나의 장식은 상기 적어도 하나의 데이터 타입의 하나 이상의 필드들이 상기 데이터 타입에 대한 고유 키(unique key)여야 함을 명기하는 속성을 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
9. 제1항에 있어서, 상기 적어도 하나의 장식은 일대일 관계를 명기하는 속성을 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
10. 제1항에 있어서, 상기 적어도 하나의 장식은 상기 적어도 하나의 데이터 타입의 필드가 또 다른 데이터 구조 내의 객체에 대한 백 포인터(back pointer)여야 함을 명기하는 속성을 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
11. 제1항에 있어서, 상기 적어도 하나의 데이터 타입에 대응하는 상기 프로그래밍 코드의 세그먼트에 정의된 적어도 하나의 필드는 장식되지 않으며, 장식의 부재는 일대다 관계가 존재하여야 함을 나타내는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
12. 제1항에 있어서, 상기 데이터 스토어는 딕셔너리(dictionary), 컬렉션, 및 어레이 중 하나를 포함하는, 데이터베이스 구조 결정 및 데이터 스토어 생성 컴퓨터 구현 방법.
13. 데이터베이스 구조를 동적으로 결정하고, 하나 이상의 데이터 타입들의 객체들을 저장하며 상기 객체들에 대응하는 데이터를 저장하기 위한 데이터 스토어를 생성하는 방법으로서, 상기 방법은 제1항의 단계들을 포함하고,

    상기 데이터 스토어에 저장될 데이터를 수신하는 단계;

    테이블들을 검사하고 식별자 속성으로 장식된 각각의 필드를 검사하는 것을 포함하여 상기 데이터가 이미 저장되었는지를 결정하는 단계;

    상기 데이터가 이미 저장되지 않았다고 결정하면, 상기 프로그래밍 코드의 세그먼트 및 상기 결정된 데이터베이스 구조에 제공된 상기 장식 및 설명에 따라서 상기 데이터베이스 구조에 상기 데이터를 저장하는 단계;

    상기 데이터가 이미 저장되었다고 결정하면, 이미 저장된 상기 데이터에 대한 포인터들을 결정하고, 또 다른 위치에 저장된 데이터에 대해 포인팅하기 위한 포인터를 작성하는 단계

    를 더 포함하는 데이터베이스 구조 결정 및 데이터 스토어 생성 방법.
14. 컴퓨팅 시스템에 의해 실행될 때, 제1항의 방법을 구현하는 컴퓨터 실행가능 명령어들을 갖는 하나 이상의 컴퓨터 판독가능 저장 매체.
15. 컴퓨팅 시스템에 의해 실행될 때, 제13항의 방법을 구현하는 컴퓨터 실행가능 명령어들을 갖는 하나 이상의 컴퓨터 판독가능 저장 매체.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제

Images