KR20020066836A

KR20020066836A - 계층적 데이터구조를 기록한 기록매체 및 계층적 데이터저장구조를 형성하는 방법

Info

Publication number: KR20020066836A
Application number: KR1020010007268A
Authority: KR
Inventors: 김성룡; 김성규; 강인수; 백관형; 곽지숙
Original assignee: 한국통신정보기술 주식회사; 정보통신연구진흥원
Priority date: 2001-02-14
Filing date: 2001-02-14
Publication date: 2002-08-21

Abstract

본 발명에 따라 스토어 계층과 클래스 계층을 포함하는 계층적 데이터 구조를 기록한 기록 매체에서 상기 데이터구조는, 상기 스토어 계층이 포함하는 스토어에 관한 정보와 상기 스토어 계층이 포함하는 클래스에 관한 정보와 상기 스토어 계층의 속성에 관한 정보를 저장하는 스토어 헤더정보와, 상기 클래스 계층이 포함하는 인덱스에 관한 정보와 상기 클래스 계층이 포함하는 인스턴스에 관한 정보와 상기 클래스 계층의 속성에 관한 정보를 저장하는 클래스 헤더정보와, 인덱스 정보와, 인스턴스 정보를 포함한다. 본 발명에 의하면, 데이터의 공통적인 속성을 중복적으로 저장하지 않고 계층적으로 데이터를 저장함으로써, 데이터 기억 공간의 낭비를 방지할 수 있고, 데이터의 갱신시에도 상당한 오버헤드를 줄일 수 있다.

Description

계층적 데이터구조를 기록한 기록매체 및 계층적 데이터 저장구조를 형성하는 방법{Recording medium for recording hierarchical data structure and method for creating hierarchical data storage structure}

본 발명은 계층적 데이터 구조에 관한 것으로, 좀더 구체적으로는, 계층적 데이터 구조를 기록한 기록매체 및 계층적 데이터 저장구조를 형성하는 방법에 관한 것이다.

지리정보 시스템에서 처리하는 대상은 실세계의 공간을 표현하는 지리정보 데이터로 구성되고 완벽한 지리 정보 데이터를 표현하기 위해서는 공간 정보와 비공간 속성정보가 함게 정의되어야 한다. 공간 정보는 각종 지리 현상의 위치와 형상 및 사상간의 공간상 상대적 위치 관계를 말하는데 지도상에서는 점, 선, 면을 이용하여 표시된다. 비공간 속성 정보는 점, 선, 면으로 표시된 각종 좌표상의 정보를 제공하는 특성이나 속성을 말한다. 공간정보와 비공간 속성정보가 하나로 연결된 것을 feature라고 하며 이것이 비로소 하나의 의미있는 지리 정보 데이터의 단위가 된다. 이와 같이 지리 정보 데이터가 위치를 나타내기 위해 표현되는 좌표값 즉, 공간정보 또는 비속성정보를 가지고 있다는 특성 때문에 일반적인 데이터베이스 관리 시스템으로는 복잡 다양한 지리 정보 데이터를 처리하기에는 부족함이 많다.

공간정보와 속성 정보를 효율적으로 관리하기 위한 일반 데이터베이스의 확장 개념으로 공간 데이터베이스 관리 시스템이 나타나게 되었다. 공간 데이터베이스 관리 시스템은 속성과 비속성을 하나로 관리함으로써 다양한 분야의 지리정보 시스템을 뒷받침하고 있다.

한편, 도 5에 종래의 일반적인 데이터저장구조가 도시되어 있다. 인스턴스 1 내지 인스턴스 5가 서울, 성북구, 안암동이라는 속성을 가지고 있고, 인스턴스 6 내지 인스턴스 10이 서울, 강북구, 수유동이라는 속성을 가지는 경우, 도 5에 도시된 자료 저장 구조에서는 동일한 속성값에 대해서 5번의 중복이 발생되고 있음을 알 수 있다. 또한, 속성값의 갱신시에는, 예를 들어 성북구와 강북구가 합쳐져서 하나의 새로운 성북강북구로 탄생되었을 때에는 인스턴스 1 내지 인스턴 5의 성북구 필드와 인스턴스 6 내지 인스턴스 10의 강북구 필드에 대해서 10번의 데이터 갱신이 필요함을 알 수 있다. 이렇게 중복되는 데이터에 대해서 매번 디스크 공간을 할당하는 것은 상당한 기억공간의 낭비를 가져오며, 또한 그렇게 중복적으로 데이터를 저장함으로써 데이터의 갱신시에도 상당한 오버헤드가 발생한다는 문제점이 있다.

본 발명은 상기와 같은 문제점을 해결하고자 계층성을 가지는 데이터에 대해서 데이터의 중복 저장을 방지하여 계층적인 자료 저장 구조를 형성함으로써, 기억공간의 낭비를 방지하고 기억공간의 데이터 갱신시 오버헤드를 감소시키는 것을 목적으로 한다.

도 1은 본 발명에 따라 지리 정보 처리를 위한 전체 시스템 블럭도.

도 2는 도 1에 도시된 저장 시스템의 자료 저장 구조의 상세도.

도 3은 도 2에 도시된 자료 저장 구조의 개념을 논리적으로 설명하기 위한 블럭도.

도 4a는 도 2에 도시된 자료 저장 구조에 저장되는 자료를 더 상세히 설명하기 위한 도면.

도 4b는 스토어 헤더 정보가 포함하는 필드를 도시하는 도면.

도 4c는 클래스 헤더 정보가 포함하는 필드를 도시하는 도면.

도 4d는 인덱스 정보가 포함하는 필드를 도시하는 도면.

도 4e는 인스턴스가 포함하는 클래스 형태를 도시하는 도면,

도 5는 종래 데이터 저장구조의 일예를 도시하는 도면.

도 6은 본 발명에 따른 데이터 저장구조의 일예를 도시하는 도면.

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

100 : 저장 시스템 110 : 엔진

120 : 스토어 130 : 응용 프로그램 인터페이스

지리정보 데이터는 일반적인 속성 데이터인 이름이나 주소와 같은 문자 데이터나 숫자 데이터들 뿐만 아니라 좌표와 같은 위치를 나타내는 다차원 단일 데이터도 포함한다. 그리고 이 다차원 단일 데이터는 문자나 숫자 데이터와는 달리 정렬이 까다로우며 색인이 용이하지 못하다. 그리고 위치라는 특성으로 인하여 지리정보 데이터는 계층적인 구조를 가진다.

예를 들어 지리 정보 데이터의 위치값이 (100,100)이라는 하나의 지점을 대표하는 위치값을 가진다고 하는 경우 이 데이터의 의미는 이 위치값만으로는 구분할 수 있는 방법이 없으며 이 데이터에 대한 비공간 속성을 이용하여야 한다. 즉, 지리정보 데이터는 위치정보와 그에 대한 속성정보를 함께 다루어야 제대로 활용할 수 있게 된다. 이러한 특성을 반영한 구조가 레이어(클래스) 구조이며, 이러한 클래스는 지리정보 데이터의 속성에 의한 구분을 가능하게 한다. 본 발명에 따른 저장 구조는 지리정보 데이터의 특성인 계층성을 충분히 반영하여 계층적인 저장구조를 유지한다. 본 명세서에서 본 발명에 따른 저장 구조는 주로 지리 정보 데이터에 대해 적용되는 것으로 설명하지만, 본 발명에 따른 저장 구조는 지리정보 데이터에 제한되는 것은 아니며, 계층성을 가지는 데이터라면 어떠한 데이터라도 적용될 수 있다는 것은 당업자라면 충분히 이해할 것이다.

저장된 데이터베이스를 가리키는 용어는 RDBMS에서는 db라고 하는데 비하여 본 발명에서는 스토어라고 한다. 스토어는 데이터베이스 전체에 대한 관리와 아울러 데이터베이스가 가지는 각각의 데이터 묶음(클래스)들을 관리한다. 데이터베이스내의 각각의 데이터 묶음을 RDBMS에서는 테이블로 부르는 반면 본 발명에서는 클래스라는 용어로 부른다. 클래스는 비슷한 속성을 지니는 지리 정보 데이터의 묶음이다. 클래스는 객체에 대한 관리와 효과적인 객체 검색을 위한 색인과 아울러 객체의 속성 정보들을 관리하는 기능을 수행한다. 클래스는 객체의 속성 뿐만 아니라 클래스 자체의 속성을 지니며 이를 property라고 한다. 이를 클래스 계층에 유지함으로써 지리 정보 데이터가 가지는 공통되는 속성들을 각 데이터에 중복적으로 저장하는 낭비를 효과적으로 줄일 수 있다. 이러한 property는 Class만 가지고 있는 것이 아니라 Store도 역시 가지고 있으며 계층적인 저장 구조에서 계층성을 보이기 위한 핵심적인 요소가 된다.

본 발명의 하나의 특징은, 스토어 계층과 클래스 계층을 포함하는 계층적 데이터 구조를 기록한 기록 매체가, 상기 스토어 계층이 포함하는 스토어에 관한 정보와 상기 스토어 계층이 포함하는 클래스에 관한 정보와 상기 스토어 계층의 속성에 관한 정보를 저장하는 스토어 헤더정보와, 상기 클래스 계층이 포함한 인덱스에 관한 정보와 상기 클래스 계층이 포함한 인스턴스에 관한 정보와 상기 클래스 계층의 속성에 관한 정보를 저장하는 클래스 헤더정보와, 인덱스 정보와, 인스턴스 정보를 포함하는 것이다.

본 발명의 다른 특징은, 상기 스토어 계층이 포함한 스토어에 관한 정보는 상기 스토어의 이름에 관한 정보와 상기 스토어의 개수에 관한 정보를 포함하고, 상기 스토어 계층이 포함한 클래스에 관한 정보는 상기 클래스의 이름에 관한 정보와 상기 클래스의 개수에 관한 정보를 포함하는 것이다.

본 발명의 또다른 특징은, 상기 스토어 계층이 둘 이상인 것이다.

본 발명의 또다른 특징은, 계층적 데이터 구조를 기록한 기록매체에서,상기 계층적 데이터 구조가, 스토어 계층과, 클래스 계층과, 인덱스와, 인스턴스를 포함하고, 상기 스토어 계층은 상기 클래스 계층을 포함하고, 상기 클래스 계층은 상기 인덱스와 상기 인스턴스를 포함하고, 상기 스토어 계층은 상기 스토어 계층이 포함하는 상기 클래스 계층에 관한 정보와 상기 클래스 계층의 공통적인 속성에 관한 정보를 관리하고, 상기 클래스 계층은 상기 클래스 계층이 포함하는 상기 인덱스에 관한 정보와 상기 클래스 계층이 포함하는 인스턴스의 공통적인 속성에 관한 정보를 관리하는 것이다.

본 발명의 또다른 특징은, 상기 스토어 계층에는 하나이상의 스토어가 포함되고, 상기 클래스 계층에는 하나이상의 클래스가 포함되며, 상기 스토어 계층이 포함하는 상기 클래스 계층에 관한 정보는, 상기 스토어 계층에 포함된 각 스토어가 포함하는 클래스의 이름과 개수에 관한 정보인 것이다.

본 발명의 또다른 특징은, 상기 인스턴스가 지리정보 데이터인 것이다.

본 발명의 또다른 특징은, 컴퓨팅 환경에서 스토어 계층과 클래스 계층을 포함하는 계층적 데이터 저장구조를 형성하는 방법에 있어서, 스토어 계층에는, 상기 스토어 계층이 포함한 스토어에 관한 정보와 상기 스토어 계층이 포함한 클래스에 관한 정보와 상기 스토어 계층의 속성에 관한 정보를 저장하는 스토어 헤더정보를 형성하는 단계와, 클래스 계층에는, 상기 클래스 계층이 포함한 인덱스에 관한 정보와 상기 클래스 계층이 포함한 인스턴스에 관한 정보와 상기 클래스 계층의 속성에 관한 정보를 저장하는 클래스 헤더정보를 형성하는 단계와, 인덱스를 형성하는 단계와, 인스턴스를 형성하는 단계를 포함하는 것이다.

본 발명의 또다른 특징은 계층적 데이터 저장구조를 형성하는 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것이다.

이제, 첨부된 도 1 내지 6을 참조하여 본 발명을 상세히 설명한다.

도 1은 본 발명에 따른 저장 시스템(100)과 상기 저장 시스템을 이용하는 응용 프로그램 인터페이스(130)를 도시한다. 저장 시스템(100)은 지리 정보 데이터를 저장하는 Store(120)와 검색 및 연산을 하는 엔진(110)을 포함한다. 본 발명에 따른 계층적인 저장 구조는 스토어(120)에 나타나며, 이는 첨부된 도 2 내지 6을 참조하여 상세히 설명된다.

도 2는 본 발명에 따른 저장 구조 시스템의 일예를 보여준다. 스토어11(200)은 스토어21(210), 스토어22(220), 스토어23(230)을 포함하며, 다시 스토어21은 클래스31(240), 클래스32(250), 클래스33(260)을 포함하며, 스토어22는 클래스34(270), 클래스35(280)를 포함하며, 스토어23은 클래스36(290)을 포함한다. 또한, 각 클래스는 인덱스와 인스턴스를 포함한다. 이와 같이 Tree 형태의 계층적인 저장 구조는, 예를 들어, 도 3에 볼 수 있는 것처럼 운영체제의 파일시스템에서와 같이 스토어는 폴더에, 클래스는 파일에 대응된다고 할 수 있다. 스토어는 하나 이상의 스토어와 하나 이상의 클래스를 포함할 수 있으며, 클래스 또한 하나 이상의 인덱스와 하나 이상의 인스턴스를 포함할 수 있다.

이제, 도 4a 내지 도 4e를 참조하여 본 발명에 따라 물리적인 디스크에 저장되는 계층적 저장 구조를 상세히 설명한다. 도 4a는 도 2와 도 3에 도시된 계층형저장 구조가 실제 데이터기억장치에 저장되는 형태를 도시한 것이다. 계층적인 순서는 왼쪽에서 오른쪽으로, 위에서 아래로 진행하며, 스토어11헤더정보와, 스토어11에 포함된 스토어21, 스토어22, 스토어23에 대한 헤더정보인 스토어21헤더정보, 스토어22헤더정보, 스토어23헤더정보와, 스토어21에 포함된 클래스31, 클래스 32, 클래스33에 관한 헤더정보인 클래스31헤더정보, 클래스32헤더정보, 클래스33헤더정보와, 스토어22에 포함된 클래스34와, 클래스35에 관한 헤더정보인 클래스34헤더정보와, 클래스35헤더정보와, 스토어23에 포함된 클래스36에 관한 헤더정보인 클래스36헤더정보와, 각 클래스에 포함된 인덱스와 인스턴스가 기억되어 있다.

Store는 데이터베이스 전체에 대한 정보들을 관리하는데, Store 자체의 property 정보와, 환경설정 관련정보들과, 내포된 Store나 Class를 관리하기 위한 정보들을 관리한다.

Class는 실제 Instance에 대한 저장 관리를 담당하는 클래스로써, 비슷한 속성의 Instance에 대한 묶음(Layer)들 즉 Class를 관리하며,Instance의 관리뿐만 아니라 Instance에 대한 검색을 효과적으로 하기 위한 색인에 대한 관리도 담당하며, 인스턴스의 공통적인 속성을 저장하기 위한 property 정보를 관리한다. 하나의 Class가 생성되면 자동적으로 Instance에 대한 기본 속성과 그 속성에 대응되는 기본 색인이 생성되는데, 이 두가지는 Instance의 저장관리 및 검색에 반드시 필요한 속성이며 색인이다. 이중에서 디폴트 속성은 각각 OID(Object Identifier)와 MBR(Minimum Bounding Rectangle)이다. OID는 Instance를 식별할 수 있는 유일한식별자이고 MBR은 공간 위치에 의한 Instance의 식별에 사용되는 중요한 키이다. 그리고, 이 OID에 대하여는 B+-Tree가 자동적으로 생성되며 MBR에 대하여는 R*-Tree가 자동적으로 생성된다. 이 두가지 기본 속성 이외에 추가로 여러가지의 속성의 추가가 가능하며 각 속성에 대하여 별도의 색인을 구성할 수 있다.

이제, 도 4b 내지 도 4e를 참조하여 도 4a에 도시된 스토어헤더, 클래스헤더, 인덱스, 인스턴스에 포함되는 필드정보에 대해 구체적으로 설명한다.

1. Store 헤더 정보

Store 헤더 정보는 해당 스토어의 이름과 해당 스토어가 포함하는 하위 계층의 스토어나 클래스에 관한 정보와 스토어 자체의 property를 관리한다. 도 4b에서 스토어11헤더정보(400)에 배열되는 자료구조 필드는 Store 클래스와, StoreID 클래스와, ClassID 클래스에 의해 적어도 number_of_store(401)와, number_of_class(402)와, name(403)과, storeids(404)와, classids(405)와, property(406)를 포함한다.

number_of_store(401) 필드에는 해당 계층의 스토어가 그 하위 계층으로 포함하는 스토어의 개수를 나타내는 정보가 포함되고, number_of_class(402) 필드에는 해당 계층의 스토어가 그 하위 계층으로 포함하는 클래스의 개수를 나타내는 정보가 포함되고, name(403) 필드에는 해당 계층의 스토어의 이름에 관한 정보가 포함되며, storeids(404) 필드에는 해당 계층의 스토어가 그 하위 계층으로 포함하는 스토어에 관한 정보가 포함되며, classids(405) 필드에는 해당 계층의 스토어가 그 하위 계층으로 포함하는 클래스에 관한 정보가 포함된다. storeids(404)와classids(405)는 해당 계층의 스토어가 포함하는 하위 계층의 스토어 및 클래스의 개수만큼 포함될 수 있다. property(406) 필드에는 해당 스토어 계층에 포함된 인스턴스들의 공통적인 속성을 나타내는 정보가 포함된다. 이와 같이 property(406) 필드에 포함되는 정보가 스토어 자체의 속성을 나타내며, 이와 같은 정보를 유지함으로써 지리 정보 데이터가 가지는 공통되는 속성들을 각 데이터에 중복적으로 저장하는 것을 방지할 수 있다.

예를 들어, 도 4b의 스토어11 헤더정보(400)에는 다음과 같은 Store 클래스(데이터구조 1)와 StoreID 클래스(데이터구조 2)와 ClassID(데이터구조 3)에 의해 생성되는 정보가 기억될 수 있다.

[데이터 구조 1] Store

class Store {

version_tversion;

server_tserver;

number_tnumber_of_store

number_tnumber_of_class;

border_tborder;

string_tname;

number_tmax_number_of_store;

number_tmax_number_of_class;

number_tmax_number_of_attrib;number_tmax_number_of_users;

number_tsizeof_block;

number_tsizeof_page;

number_tsizeof_page_btree;

number_tsizeof_page_rtree;

StoreIDstoreids[number_of_store];

ClassIDclassids[number_of_store];

};

위 자료구조의 각 필드를 설명하면, version은 저장 구조 시스템의 버전 정보, server는 저장 구조 시스템이 설치된 서버의 IP주소, number_of_store는 하위 Store의 개수, number_of_class는 하위 Class의 개수, border는 공간 데이터의 경계, name은 Store의 이름, max_number_of_store는 최대한 가질 수 있는 하위 Store의 개수, max_number_of_class는 최대한 가질 수 있는 하위 Class의 개수, max_number_of_attrib는 최대한 가질수 있는 속성의 개수, max_number_of_users는 최대한 가질 수 있는 동시 접속 사용자의 수, sizeof_block은 디스크 입출력 단위의 최소 크기, sizeof_page는 디스크 입출력 단위의 최적 크기, sizeof_page_btree는 B+-Tree를 위한 디스크 입출력 단위의 최적 크기, sizeof_page_rtree는 R*-Tree를 위한 디스크 입출력 단위의 최적 크기, storeids는 하위 Store 관리를 위한 ID들, classids는 하위 Class 관리를 위한 ID들을 나타낸다. 상기 일예에서는 다수의 정보를 포함하는 필드를 포함하였지만, 본 저장 구조 시스템의 계층성을 구현하기 위해 필요한 필드 정보들은 도 4b에 도시된 5개의 필드들로 충분하다는 것은 당업자라면 잘 이해할 수 있을 것일다. 또한 상기 일예에서는 property 필드를 예시하지 않았지만, Store 계층에서는 property 필드에 포함되는 속성 정보가 포함되어도 좋고 포함되지 않아도 좋다.

[데이터 구조 2] Store ID

class StoreID {

number_tdepth

string_tname;

};

여기에서, depth는 해당 Store가 상위 Store내에서 위치하는 층의 깊이 또는 레벨, name는 해당 Store의 이름을 나타낸다.

[데이터 구조 3] Class ID

class ClassID {

number_tused;

number_ttype;

number_tlayer;

string_tname;

};

여기에서, used는 해당 클래스가 사용되는지 안되는지를 나타내는 필드이고, type는 해당 클래스의 타입 즉, node, point, edge, face 등의 타입을 나타내고, layer는 해당 Class라는 클래스의 고유 번호와 같은 것을 나타내며, name은 해당Class의 이름을 나타낸다.

2. Class 헤더 정보

Class 헤더 정보는 데이터베이스내의 클래스에 대한 생성, 삭제, 수정과 아울러 색인의 생성과 삭제도 담당하며 객체의 생성과, 삭제, 검색 기능을 수행한다.

도 4c에 클래스31헤더정보(420)에 기억되는 자료구조 필드는 Class 클래스와 IndexID 클래스에 의해 적어도 type(421), layer(422), number_of_attrib(423), number_of_instance(424), name(425), number_of_indices(426), indexids(427), attribs(428), property(429) 필드를 포함한다. type(421) 필드에는 Class의 공간 데이터의 타입에 관한 정보가 포함되고, layer(422) 필드에는 Class의 레이어를 나타내는 정보가 포함되고, number_of_attrib(423) 필드에는 attribute의 개수를 나타내는 정보가 포함되고, number_of_instance(424) 필드에는 인스턴스의 개수를 나타내는 정보가 포함되고, name(425) 필드에는 Class의 이름에 관한 정보가 포함되고, number_of_indices(426)필드에는 해당 클래스가 포함하는 인덱스의 개수에 관한 정보가 포함되고, indexids(427) 필드에는 해당 클래스가 포함하는 인덱스에 관한 정보가 포함되고, attribs(428) 필드에는 해당 클래스가 포함하는 attribute에 관한 정보를 포함한다. property(429) 필드에는 해당 클래스 계층에 포함된 인스턴스들의 공통적인 속성을 나타내는 정보가 포함된다. 이와 같이 property(429) 필드에 포함되는 정보가 클래스 자체의 속성을 나타냄으로써 지리 정보 데이터가 가지는 공통되는 속성들을 각 데이터에 중복적으로 저장하는 것을 방지할 수 있다. 이러한 property는 계층적인 저장 구조에서 계층성을 보이기 위한 특성중의 하나이다.

Class 자체의 속성인 Property는, 예를 들어, 지리 정보 데이터의 디스플레이 성능을 향상시키기 위하여 저장 시스템 수준에서 Instance의 디스플레이가 가능하도록 지원하기 위한 디스플레이를 위한 속성들이 될 수 있다. 이 속성은 하나의 Class에 속한 Instance에 대한 공통적인 디스플레이 속성들을 정의하는 것으로 Instance의 색깔, 내부를 채우는 경우의 채우는 색깔, 그리고 채우기 위한 패턴, 선의 굵기, 비공간속성들을 디스플레이하는데 사용되는 폰트의 종류나 색깔들을 정의한다. 이러한 속성이 바로 Class의 Property이며, 이와 같이 디스플레이에 사용되는 속성중 공통되는 속성을 Class 계층의 Property 필드에 저장함으로써 각 인스턴스 데이터 마다의 중복 저장을 방지할 수 있다.

Class는 Instance에 대한 저장 관리와 아울러 검색의 효율성을 극대화하기 위한 색인들에 대한 생성 및 삭제 등과 같은 관리 기능도 가진다. 검색을 위한 색인 방법은 실제로는 Index라는 클래스에 의하여 관리되며, 이 Index는 실제 색인 방법들을 위한 추상 클래스이다. 즉, Class가 색인의 방법에 구애받지 않고 색인 방법을 관리할 수 있는 방법을 제공하는 것이다. Store가 Class에 대한 정보를 classid를 통하여 알아내듯이 Class는 indexid를 통하여 index에 대한 정보를 알아내는 방법을 취한다. 예를 들어, 도 4의 클래스 31헤더정보(440)에는 다음과 같은 Class 클래스(데이터구조 4)와 IndexID 클래스(데이터구조 5)에 의해 생성되는 정보가 기억될 수 있다.

[데이터구조 4] Class

class Class {

number_ttype;

number_tlayer;

number_tsizeof_block;

number_tsizeof_page;

number_tnumber_of_attrib;

number_tnumber_of_instance;

border_tborder;

string_tname;

string_talias;

record_trecord_manager;

booleandraw_enable;

number_tdraw_red;

number_tdraw_green;

number_tdraw_blue;

booleandraw_enable;

number_tdraw_red;

number_tdraw_green;

number_tdraw_blue;

number_tdraw_style;

number_tfill_style;

number_tdraw_width;

number_tdraw_level;

number_tfont_style;

number_tfont_red;

number_tfont_green;

number_tfont_blue;

number_tnumber_of_indices;

IndexIDindexids[number_of_indices];

Attributeattribs[number_of_attrib];

};

여기에서, type은 Class의 공간 데이터 타입(node, edge, line, face중 하나), layer는 Class의 layer, sizeof_block은 디스크 입출력 단위의 최소 크기(Store의 기본값 이용), sizeof_page는 디스크 입출력 단위의 최적 크기(Store의 기본값 이용), number_of_attrib는 속성의 개수, number_of_instance는 객체의 개수, border는 공간 데이터의 경계, name은 Class의 이름, alias는 Class의 별명, record_manager는 객체 관리기, draw_enable은 그리기 유무,draw_red, draw_green, draw_blue는 그리기 색깔, draw_enable은 채우기 유무, draw_red,draw_green,draw_blue는 채우기 색깔, draw_style은 그리기 스타일,fill_style은 채우기 스타일, draw_width는 그리기 두께, draw_level는 그리기 레벨, font_style은 폰트 스타일, font_red, font_green,font_blue는 폰트 색깔, number_of_indices는 인덱스의 개수, indexids는 인덱스 관리를 위한 ID, attribs는 데이터의 속성값을 관리하기 위한 정보를 나타낸다.

[데이터구조 5] Index ID

class IndexID {

booleanused;

number_ttype;

number_tsizeof_key;

number_ttypeof_key;

number_tname[32];

};

여기에서, type는 B트리인지 R트리인지를 나타내는 필드이고, sizeof_key는 key의 크기 즉 인덱스를 위한 키의 크기, typeof_key는 key의 종류 즉 문자인지 숫자인지를 나타내는 필드이고, name은 IndexId의 이름을 나타낸다.

3. Index

Index는 Class가 관리하는 Instance에 대한 검색을 효과적으로 하기 위한 색인을 관리하는 클래스로써 몇가지 기본 속성을 가진다. 비공간 색인 방법으로는 B+-Tree를, 공간 색인 방법으로는 R*-Tree를 채택한다. 도 4d에 도시된 인덱스(430)에 기억되는 자료구조 필드는 Index 클래스에 의해 적어도 number(431), height(432), type(433), name(434), sizeof_key(435),typeof_key(436)를 포함한다. number(431) 필드에는 해당 인덱스에 삽입된 인스턴스의 개수를 나타내는 정보가 포함되고, height(432) 필드에는 해당 인덱스의 높이를 나타내는 정보가 포함되고, type(433) 필드에는 인덱스의 종류를 나타내는 정보가 포함되고, name(434) 필드에는 인덱스의 이름을 나타내는 정보가 포함되고, sizeof_key(435) 필드에는 데이터의 키의 크기를 나타내는 정보가 포함되고, typeof_key(436) 필드에는 데이터의 키의 종류를 나타내는 정보가 포함된다.

예를 들어, 도 4d의 인덱스(430)에는 다음과 같은 Index 클래스(데이터구조 6)에 의해 생성되는 정보가 기억될 수 있다.

[데이터구조 6] Index

class Index {

number_tnumber;

number_theight;

number_tmax_of_height;

number_ttype;

number_trate;

number_tunique;

string_tname;

number_tsizeof_page;

number_tsizeof_key;

number_ttypeof_key;

page_tpage_manager;

};

여기서, number는 색인에 삽입된 객체의 개수, height는 색인의 높이, max_of_height는 색인의 최대 높이, type은 색인의 종류( B+-Tree,R*-Tree), rate는 하나의 노드를 채우기 위한 최소 비율, unique는 데이터의 키의 중복성 유무, name은 색인의 이름, sizeof_page는 디스크 입출력 단위의 최적 크기, sizeof_key는 데이터의 키의 크기, typeof_key는 데이터의 키의 종류(수, 문자 등), page_manager는 각 노드들을 관리하기 위한 관리기를 나타낸다.

4. Feature

인스턴스(440)는 도 4e에 도시한 바와 같이 Attribute 클래스(441)와, Feature 클래스(442)와, OID 클래스(443)와, Geometry 클래스(444)와, Value 클래스(445)를 포함한다. 일예로, 도 4e의 인스턴스(440)에는 아래와 같은 Attribute 클래스(데이터구조 7)와, Feature 클래스(데이터구조 8), OID 클래스(데이터구조 9)와, Geometry 클래스(데이터구조 10)와, Value 클래스(데이터구조 11)에 의해 생성되는 정보가 기억될 수 있다.

Attribute 클래스(441)는 Instance에 대한 관리를 위하여 Instance의 속성에 대한 정보들을 관리한다. 이 Attribute 클래스는 속성의 종류와 속성의 크기, 속성의 대표이름등을 관리하는 기능을 가지며, 속성 각각에 대한 색인 관리를 위한 IndexID 필드를 가진다.

[데이터구조 7] Attribute

class Attribute {

number_ttype;

boolean has_index;

number_tsize;

number_toffset;

string_tname;

string_talias;

IndexIDiid;

};

여기에서, type는 node, line, edge, face 등의 형을 나타내고, has_index는 인덱스를 가지는지 안가지는지를 나타내는 필드이고, size는 key의 크기, offset은 attribute값이 위치하는 곳, name은 attribute의 이름, alias는 attribute의 별명, iid는 IndexID의 이름을 나타낸다.

Feature 클래스(442)는 Store와 Class, Index의 상관관계에 의하여 Instance를 저장 관리하며, Class나 Index는 Feature 클래스를 통하여 실제 Instance에 대한 여러가지 연산 및 작업들을 수행한다. Feature 클래스는 여러가지의 자료구조의 복합체로 구성되어지며, Class에 대한 정보, Insatnce를 식별하는 OID에 대한 정보, 공간속성을 나타내는 Geometry 클래스와, 비공간 속성을 관리할 수 있는 Value 클래스를 포함한다. 일예로 Feature 클래스는 다음과 같다.

[데이터구조 8] Feature

class Feature {

Class&class;

OIDoid;

Geometrygeometry;

Valuevalue;

};

OID 클래스(443)는 5개의 정보 필드로 구성되어 있으며, 이 필드들은 physical OID를 지원하는데 사용되어 진다. 저장구조에서 인스턴스에 대한 관리는 OID를 통하여 이루어지는데, OID라는 것은 인스턴스를 구분할 수 있는 식별자로서 일반적으로 logical OID와 physical OID로 구분된다. 논리적 OID는 말 그대로 논리적인 식별자로써 인스턴스가 저장되어진 위치에 무관하게 인스턴스를 식별할 수 있는 방법을 사용한 OID를 의미하는 것이고 물리적 OID는 인스턴스가 저장된 위치에 의존적인 OID를 의미한다. 물리적 OID는 OID 자체에 인스턴스에 대한 위치 정보가 존재하고 있어 인스턴스에 대한 직접적인 접근이 가능한 데 비하여 논리적 OID는 그러한 정보가 없고 OID 매핑 테이블이 존재하여 실제 인스턴스에 대한 정보는 이 OID 매핑 테이블에 존재하기 때문에 인스턴스에 대한 접근이 매핑과정을 거쳐야 가능하게 된다. 일예로 OID 클래스는 다음과 같다.

[데이터구조 9] OID (Object Identifier)

class OID {

number_ttype;

number_tlayer;

number_tsize;

number_tserial

number_toffset;

};

여기에서, type과 layer는 Class가 가지는 type과 layer 필드와 동일한 의미이며, size는 Instance 하나의 크기를 나타낸다. 그리고 serial은 Instance에 대한 논리적인 식별자이고 오프셋은 Instance에 대한 물리적인 식별자이다.

Geometry 클래스(444)는 상위추상 클래스로써 모든 공간 속성의 공통값인 MBR만을 유지하고 있으며, 기타 위치 정보를 위한 좌표값은 하위 클래스에서 유지한다. 그리고, 하위 클래스인 Node, Edge, Line, Face 등도 실제 좌표값을 유지하는 것이 아니며 좌표값을 위한 클래스를 포함하도록 되어 있다. 그리고, Node, Edge, Line, Face 클래스들은 지리 정보 데이터에 대한 연산 기능의 인터페이스 역할을 담당한다. 실제 좌표값에 대한 공간 연산은 모두 Point, LSeg, Poly에서 이루어지며 실제로 모든 지리 정보 데이터들은 이 세가지의 클래스들의 적절한 조합으로 표현가능하다.

일예로, Geometry 클래스의 데이터 구조는 다음과 같다.

[데이터구조 10] Geometry

class Geometry {MBRmbr;

};

class Node : Geometry {

Pointpoint;

};

class Edge : Geometry {

LSeglseg;

};

class Line : Geometry {

Polypoly;

};

class Face : Geometry {

Polypoly;

};

class Point {

double_tx;

double_ty;

};

class LSeg {

Pointsp;

Pointep;

};

class Poly {

number_tnumberof_point;

Pointpoints;

};

class MBR {

Pointmin;

Pointmax;

};

Value 클래스는 Class가 가지는 Instance의 속성정보인 Attribute에 대응되는 실제 Instance의 속성값들을 유지 관리한다. Value는 종류와 함께 값들을 저장할 수 있는 구조를 가지고 있으며, 이 구조는 연산을 위한 메모리상의 구조를 나타낸다. 즉 Class와 OID를 이용하여 Instance의 값을 Feature에 읽어 들이는 경우에 실제 속성값이 적절하게 처리되어 적절한 필드에 유지되게 된다. Value 클래스의 데이터구조는 다음과 같다.

[데이터구조 11] Value

class Value {

number_ttype;

unionvalue {

number_tnumber;

string_tstring;

MBRmbr;

OIDoid;

Geometrygeom;

void*user;

} v;;

};

이제, 도 6을 참조하여 본 발명에 따른 자료 저장 구조에 의해 데이터의 저장에 있어 공간을 절약하고 데이터의 갱신에 있어 오버헤드를 줄일 수 있음을 설명한다.

예를 들어, 서울시 성북구 안암동, 서울시 강북구 수유동에 대한 데이터베이스를 생성하는 경우에 모든 데이터들이 주소를 가진다면 주소값중에서 서울시, 성북구, 안암동의 세 값과 서울시, 강북구, 수유동은 데이터베이스내의 모든 데이터들이 공유하는 속성값이다. 이러한 경우 기존의 RDBMS에서 데이터베이스를 생성하는 경우에는 도 5에 도시한 바와 같이 인스턴스1(500) 내지 인스턴스5(540)는 서울, 성북구, 안암동에 대한 속성값을 중복 저장하고, 인스턴스6(550) 내지 인스턴스10(590)은 서울, 강북구, 수유동에 대한 속성값을 중복 저장해야 한다.

그러나, 본 발명에 따른 저장구조에서는 Store내의 부분 데이터 집합으로 Class들이 존재하며 Class내에는 다시 데이터들이 존재하며, 이때 데이터의 속성중에서 전체가 동일한 값을 가지는 속성에 대해서는 Class나 Store에 그 속성을 유지할 수 있으므로, 도 6에 도시한 바와 같이 성북구에 관한 스토어21(610)와 안암동에 관한 클래스31(620)와 강북구에 관한 스토어22(650)와 수유동에 관한 클래스32(660)의 4 클래스만으로써 인스턴스 1 내지 10에 대한 속성을 모두 저장할 수 있다. 즉, 본 발명에 따른 자료 구조에 의해 데이터의 수 만큼의 저장 공간을 필요로 하는 속성에 대하여 훨씬 적은 수의 적은 저장 공간만으로 해결할 수 있다.

또한, 본 발명에 따른 저장 구조는 데이터의 저장시에 뿐만 아니라 데이터의 갱신 등에서도 아주 유리하다. 예를 들어, 성북구와 강북구가 합쳐져서 하나의 성북강북구로 탄생된 경우에 데이터베이스의 각 인스턴스의 속성값을 갱신해야 하는데, 도 5에서는 인스턴스1(500) 내지 인스턴스10(590)의 모두에 대해 그 속성값인 성북구 필드와 강북구 필드를 성북강북구로 수정해 주어야 하므로, 10개의 인스턴스에 대해 10회의 갱신이 필요하다. 그러나, 본 발명에 따른 저장구조에서는 도 5(b)에서 알 수 있는 바와 같이 성북구에 관한 스토어21(610)과 강북구에 관한 스토어22(650)에 대해서만 성북강북구로 갱신하면 각 인스턴스에 대한 모든 속성값이 갱신될 수 있다.

본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플라피디스크, 광데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

이상 설명한 바와 같이 본 명세서의 상세한 설명 및 도면에는 본 발명의 바람직한 형태가 설명되고 도시되었지만, 본 발명은 다른 다수의 다양한 조합 및 환경에서 이용될 수 있고 본 발명의 개념의 범위내에서 다수의 변형 및 수정이 가해질 수 있다는 것을 본 발명이 속하는 기술분야의 당업자라면 충분히 이해할 것이다.

이상 설명한 바와 같이, 본 발명의 계층적인 저장 구조 시스템에 의하면 데이터의 공통적인 속성을 중복적으로 저장하지 않고 계층적으로 데이터를 저장함으로써, 데이터 기억 공간의 낭비를 방지할 수 있고, 데이터의 갱신시에도 상당한 오버헤드를 줄일 수 있다. 본 발명에 따른 저장 구조가 계층적인 특성을 지니는 지리 정보 데이터에 이용하는 것이 바람직하지만, 본 발명에 따른 자료 저장 구조는 이에 제한되는 것은 아니며 계층성을 지니는 어떠한 데이터에라도 바람직하게 이용가능함은 물론이다.

Claims

스토어 계층과 클래스 계층을 포함하는 계층적 데이터 구조를 기록한 기록 매체에 있어서,

상기 스토어 계층이 포함하는 스토어에 관한 정보와 상기 스토어 계층이 포함하는 클래스에 관한 정보와 상기 스토어 계층의 속성에 관한 정보를 저장하는 스토어 헤더정보와,

상기 클래스 계층이 포함하는 인덱스에 관한 정보와 상기 클래스 계층이 포함하는 인스턴스에 관한 정보와 상기 클래스 계층의 속성에 관한 정보를 저장하는 클래스 헤더정보와,

인덱스 정보와,

인스턴스 정보를 포함하는 계층적 데이터 구조를 기록한 기록매체.
청구항 1에 있어서,

상기 스토어 계층이 포함하는 스토어에 관한 정보는 상기 스토어의 이름에 관한 정보와 상기 스토어의 개수에 관한 정보를 포함하고,

상기 스토어 계층이 포함하는 클래스에 관한 정보는 상기 클래스의 이름에 관한 정보와 상기 클래스의 개수에 관한 정보를 포함하는 계층적 데이터 구조를 기록한 기록매체.
청구항 1에 있어서,

상기 스토어 계층은 둘 이상인 계층적 데이터 구조를 기록한 기록매체.
계층적 데이터 구조를 기록한 기록매체에 있어서,

상기 계층적 데이터 구조는,

스토어 계층과, 클래스 계층과, 인덱스와, 인스턴스를 포함하고,

상기 스토어 계층은 상기 클래스 계층을 포함하고, 상기 클래스 계층은 상기 인덱스와 상기 인스턴스를 포함하고,

상기 스토어 계층은 상기 스토어 계층이 포함하는 상기 클래스 계층에 관한 정보와 상기 클래스 계층의 공통적인 속성에 관한 정보를 관리하고,

상기 클래스 계층은 상기 클래스 계층이 포함하는 상기 인덱스에 관한 정보와 상기 클래스 계층이 포함하는 인스턴스의 공통적인 속성에 관한 정보를 관리하는 계층적 데이터 구조를 기록한 기록매체.
청구항 4에 있어서,

상기 스토어 계층에는 하나이상의 스토어가 포함되고, 상기 클래스 계층에는 하나이상의 클래스가 포함되며,

상기 스토어 계층이 포함하는 상기 클래스 계층에 관한 정보는, 상기 스토어 계층에 포함된 각 스토어가 포함하는 클래스의 이름과 개수에 관한 정보인 계층적 데이터 구조를 기록한 기록매체.
청구항 4에 있어서,

상기 인스턴스는 지리정보 데이터인 계층적 데이터 구조를 기록한 기록매체.
컴퓨팅 환경에서 스토어 계층과 클래스 계층을 포함하는 계층적 데이터 저장구조를 형성하는 방법에 있어서,

스토어 계층에는, 상기 스토어 계층이 포함하는 스토어에 관한 정보와 상기 스토어 계층이 포함하는 클래스에 관한 정보와 상기 스토어 계층의 속성에 관한 정보를 저장하는 스토어 헤더정보를 형성하는 단계와,

클래스 계층에는, 상기 클래스 계층이 포함하는 인덱스에 관한 정보와 상기 클래스 계층이 포함하는 인스턴스에 관한 정보와 상기 클래스 계층의 속성에 관한 정보를 저장하는 클래스 헤더정보를 형성하는 단계와,

인덱스를 형성하는 단계와,

인스턴스를 형성하는 단계를 포함하는, 계층적 데이터 저장구조를 형성하는 방법
청구항 7에 기재된 계층적 데이터 저장구조를 형성하는 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.