선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 또한 기존의 XML을 저장하기 위한 스키마인 XParent는 공간 지리정보들의 표현의 한계성, 테이블 간의 데이터의 중복, 다수 테이블에 따른 검색의 비효율성의 문제점을 가진다. 따라서 본 논문에서는 XParent의 문제들을 해결하기 위해서 테이블 간의 결합을 고려하여 GML 문서의 효율적인 저장/관리를 위한 GML 저장스키마인 GParent #1, GParent #2, GParent #3를 제안하였다. 제안한 저장스키마의 효율성을 평가하기 위해 GML 문서의 삽입시간, 저장 공간 사용량 및 엘리먼트당 검색시간을 측정하였다.
- 셋째, GParent #3 는 데이터의 중복과 검색 시 별도의 테이블들의 검색을 줄이기 위해, Data 테이블, Element 테이블과 DataPath 테이블을 결합하여 하나의 테이블로 표현하는 스키마이다. 본 논문에서는 아울러 제안하는 저장 스키마를 바탕으로, GML 문서를 저장하기 위한 GML 지원 하부 저장 관리자를 설계 및 구현한다. 성능평가를 통해서 제안한 GParent 방법이 삽입 시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색 시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시한다.
제안 방법
- 예를 들면 가장 크기가 큰 famigml 문서는 총 371, 279개의 엘리먼트를 가지므로 DatalD = 1 - 371, 279 에 대한 평균 엘리먼트당 검색시간을 측정한다. DatalD가 주어질 때 결과로 나온 시간을 검색된 GML 문서가 갖는 엘리먼트 수로 나누어서 평균 엘리먼트당 검색시간을 측정한다. (그림 11)은 GML문서들의 엘리먼트당 평균 검색시간을 비교한 것이다.
- GML은 점(point), 연속선(linestrinQ, 선형링 (lineamng), 다각형 (polygon), 다중점 (multipoint), 다중연속선 (multilinestring), 다중다각형 (multipolygon), 다중지오메트리 (multigeometry) 클래스에 대한 지오메트리 엘리먼트와 좌표를 표현하기 위한 좌표(coordinate) 엘리먼트와 범위(extent) 를 정의하기 위한 상자(box) 엘리먼트를 추가적으로 제공한다. GML 3.0은 기존의 GML과의 호환성을 제공하며, 모듈화, 복합 지오메트리(Geometry), 시공간 참조시스템, 위상, 메타데이터, 그리드 데이터, 측정 단위 등을 추가하였다. 특히 GML 3.
- 또한, 제안한 저장스키마에 적합한 GML 지원 하부 저장 관리자를 설계 및 구현하였다. GML 지원 하부 저장 관리자는 GML 문서의 효율적인 검색을 위하여 일반 텍스트 색인 및 공간 지리정보의 색인을 제공하며, 아울러 외부 API를 통해서 사용자가 쉽게 접근할 수 있는 환경을 제공하였다. 하부 저장 관리자의 효율성을 평가하기 위해, GML 문서의 삽입시간, 엘리먼트당 검색시간 및 Spatial Data에 대한 검색시간을 측정하여 기존 상용 DBMS 인 Oracle과 성능비교를 수행하였다, 그 결과 GML 지원 하부 저장 관리자는 모든 평가부분에서 Oracle보다 우수함을 나타내었다.
- 이러한 최상위 인터페이스를 사용함으로써, 전체 테이블 관리를 일관성 있게 유지할 수 있다. 둘째, GML 문서의 저장 시, 테이블 manager API를 호줄하여 저장하고 이를 통해 GML 문서를 생성하여 사용자에게 반환한다. 아울러 GML 문서의 검색 시, 테이블 Manager API 를호출하여 검색을 수행한다.
- 그러나 XParent는 공간 지리정보들의 표현의 한계성, 테이블 간의 데이터의 중복, 다수 테이블에 따른 검색의 비효율성의 문제점을 가진다. 따라서 논문에서는 XParent의 문제들을 해결하기 위해서 테이블 간의 결합을 고려하여 GML 문서의 효율적 저장을 위한 3가지 저장 스키마, 즉, GParent #1, GParent #2, GParent #3를 제안한다. 첫째, GParent #1는데이터의 중복과 검색 시 별도의 Data 테이블의 검색을 줄이기 위해, Data2 테이블과 Element 테이블을 결합하여 하나의 테이블로 표현하는 스키마이다.
- (그림 3)은 3개의 결합을 나타낸다. 따라서 본 논문에서는 결합 1, 2, 3 에 각각 해당하는 GML 문서를 위한 새로운 저장 스키마 GParent #1, GParent #2, GParent #3을 제안한다.
- 하지만 XParent의 경우에는 엘리먼트에 포함된 데이터를 얻어오기 위해 Element 테이블과 Data2 테이블로부터 동일한 PathlD와 DatalD를 갖는 레코드를 검색하기 위해 조인(Join) 연산이 불가피하다. 따라서 이러한 점을 해결하기 위해 XParent의 Data2 테이블과 Element 테이블을 결합하여 하나의 테이블로 표현한다. 이러한 테이블을 Data- Element 테이블이라 하고, 또한 이렇게 확장된 저장 스키마를 GParent #1 이라고 명명한다.
- 이러한 이유로 하위 엘리먼트를 찾기 위해 DataPath 테이블과 Element 테이블과의 조인 연산은 불가피 하다. 따라서 효율적인 조인을 위해 XParent의 Element 테이블과 DataPath 테이블의 결합하여 하나의 테이블로 표현한다. 이 결합된 테이블을 Element-DataPath 테이블이라 하고, 또한 이렇게 확장된 저장 스키마를 GParent #2 라고 명명한다.
- 그 결과 GParent 방법이 삽입시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내었고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시하였다. 또한, 제안한 저장스키마에 적합한 GML 지원 하부 저장 관리자를 설계 및 구현하였다. GML 지원 하부 저장 관리자는 GML 문서의 효율적인 검색을 위하여 일반 텍스트 색인 및 공간 지리정보의 색인을 제공하며, 아울러 외부 API를 통해서 사용자가 쉽게 접근할 수 있는 환경을 제공하였다.
- 마지막으로 본 논문에서 제안한 저장스키마인 GParent #1, GParent #2, GParent #3의 검색 성능평가를 수행한다. GML 을 검색하기 위한 모든 질의는 GML 문서에서의 Data ID를 얻기 전 과정과 얻은 후의 과정으로 나뉠 수 있는데, 예를 들면 Path만을 알고 있을 때에는 Label Path 테이블에서 Path를 가지고 검색하여 Path ID를 얻는다.
- 마찬가지로 Non-Spatial 값이나 Spatial 값도 Non Spa tial Index와 Spatial Index의 검색을 통해 Data ID를 얻은 후, 해당하는 엘리먼트를 얻는다. 본 논문에서 비교하고자 하는 4개의 저장스키마의 가장 큰 차이점은 Data 테이블, Element 테이블, Data Path 테이블의 조합으로 이루어진 Data-Element, Element-DataPath, Data~Element-DataPath 이므로 DatalD를 통한 검색을 통해 검색 성능을 평가한다. V표 2>에 소개된 문서들의 모든 DatalD에 대해서 평균 검색 시간을 측정한다.
- 본 절에서는 저장스키마의 효율성을 성능평가하기 위해, 첫째로 기존 저장스키마인 XParent와 본 논문에서 제안한 3 개의 저장스키마 즉, GParent #1, GParent #2, GParent #3의 효율성을 평가한다. 효율성에 대한 항목으로는 GML 문서의 삽입 시간, 저장공간 사용량 및 엘리먼트당 검색시간을 측정한다.
- 본 절에서는 제안하는 저'장스키마중 가장 검색 효율성이 우수한 GParent #3 을 이용하여, 본 논문에서 제시한 GML 지원 하부저장관리자 및 공간 데이터의 저장이 가능한 대표적인 상업용 DBMS 인 Oracle 과 성능비교를 수행한다. 먼저 (그림 13)은 GML문서의 삽입시간 성능을 비교한 것이다.
- 본 절에서는 제안하는 저장 스키마를 바탕으로 GML 문서를 저장하기 위한 GML 지원 하부 저장 관리자를 설계 및 구현한다* 구현된 GML 지원 하부 저장 관리자는 총 5개의 모듈로 구성된다. 즉, storage manager, spatial data type manager, spatial index, non-spatial index, user interfaced.
- 본 절에서는 제안한 저장스키마를.실제 GML 문서에 적용시켰을 때의 각 테이블들의 예를 제시한다.
- 따라서 하위 엘리먼트가 존재해도 Data 테이블의 검색이 필요할 수 도 있다. 이러한 문제점을 해결하기 위해 XParent의 Data 테이블, Element 테이블과 DataPath 테이블을 결합하여 하나의 테이블로 표현한다. 이테이블을 Data-Element-DataPath 테이블이라 하고, 이렇게 확장된 저장 스키마를 GParent #3 이라고 명명한다.
- 따라서 본 논문에서는 XParent의 문제들을 해결하기 위해서 테이블 간의 결합을 고려하여 GML 문서의 효율적인 저장/관리를 위한 GML 저장스키마인 GParent #1, GParent #2, GParent #3를 제안하였다. 제안한 저장스키마의 효율성을 평가하기 위해 GML 문서의 삽입시간, 저장 공간 사용량 및 엘리먼트당 검색시간을 측정하였다. 그 결과 GParent 방법이 삽입시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내었고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시하였다.
- 둘째, 본 논문에서 제시한 GML 지원 하부 저장 관리자의 효율성을 평가하기 위해, 기존 상용 DBMS인 Oracle과 성능 비교를 수행한다. 효율성에 대한 항목으로는 GML 문서의 삽입 시간, 엘리먼트당 검색 시간 및 Spatial Data에 대한 검색 시간을 측정한다. 성능평가는 Intel Xeon 3.
- 평가한다. 효율성에 대한 항목으로는 GML 문서의 삽입 시간, 저장공간 사용량 및 엘리먼트당 검색시간을 측정한다. 둘째, 본 논문에서 제시한 GML 지원 하부 저장 관리자의 효율성을 평가하기 위해, 기존 상용 DBMS인 Oracle과 성능 비교를 수행한다.
대상 데이터
- 1)를 사용하였다. 입력 데이터는 두 종류의 데이터를 사용한다. 첫째, GML Document Type A는 (주) 대경지리정보[14] 에서 제공한 전라북도 남원시 덕과면 고정리의 데이터이고, GML Document Type B는 (주)Thinkware[15] 에서 제공한 전라북도 내 도시 데이터이다.
- 입력 데이터는 두 종류의 데이터를 사용한다. 첫째, GML Document Type A는 (주) 대경지리정보[14] 에서 제공한 전라북도 남원시 덕과면 고정리의 데이터이고, GML Document Type B는 (주)Thinkware[15] 에서 제공한 전라북도 내 도시 데이터이다. Type A 문서의 특징은 문서의 단계가 깊지 않으며, spatial Data 보다 non-spatial Data를 다소 많이 포함하고 있는 반면, Type B 문서의 특징은 문서의 단계가 깊으며, non-spatial data 보다 spatial data 를 보다 많이 포함하고 있다.
데이터처리
- 효율성에 대한 항목으로는 GML 문서의 삽입 시간, 저장공간 사용량 및 엘리먼트당 검색시간을 측정한다. 둘째, 본 논문에서 제시한 GML 지원 하부 저장 관리자의 효율성을 평가하기 위해, 기존 상용 DBMS인 Oracle과 성능 비교를 수행한다. 효율성에 대한 항목으로는 GML 문서의 삽입 시간, 엘리먼트당 검색 시간 및 Spatial Data에 대한 검색 시간을 측정한다.
이론/모형
- 넷째, 공간 데이터의 색인을 위해서는 RST API-t 사용한다. 마지막으로, Berkeley DB API를 통해서 실제 Disk와 Memory에 반영되며, 이는 Sleepycat[13]사에서 제공하는 Berkeley DB C++ 라이브러리를 사용하였다. 한편, storage manager 모듈로 Berkeley DB를 사용하는 이유는 Berkeley DB가 오픈소스 임베디드 데이터베이스 라이브러리이며, 데이터베이스로서 갖추어야 할 동시성 제어, 트랜잭션(transaction) 복구(recovery) 기법을 제공하기 때문이다.
성능/효과
- 한편, storage manager 모듈로 Berkeley DB를 사용하는 이유는 Berkeley DB가 오픈소스 임베디드 데이터베이스 라이브러리이며, 데이터베이스로서 갖추어야 할 동시성 제어, 트랜잭션(transaction) 복구(recovery) 기법을 제공하기 때문이다. Berkeley DB는 DBMS가 아닌 데이터베이스 라이브러리이기 때문에, 본 논문에서 설계한 storage manager 모듈로 적합하다고 할 수 있다.
- 따라서 spatial data 검색의 경우에는 최소 약 8배에서 최대 약 22배 까지 Oracle 에 비하여 성능이 우수함을 알 수 있다. 결론적으로 모든 평가 부분에서 본 논문에서 제시한 GML지원 하부 저장 관리자가 우수한 것을 알 수 있다. 이러한 이유는 Oracle은 범용적인 응용을 위한 DBMS인 반면, GML 지원 하부 저장 관리자는 GML 지원을 효율적으로 하기 위해 만들어진 GML 문서 전용의 하부 저장관리자이기 때문이다.
- 결론적으로 성능평가를 통해서, 삽입시간과 저장 공간 사용량은 GParent #2 저장스키마가 우수하며, 검색시간은 GParent #3 저장스키마가 우수하다. GML 문서의 삽입시간이 중요한 응용이라면 GParent #2 저장스키마를 사용하고, GML 문서의 검색시간이 중요한 응용이라면 GParent #3 저장 스키마를 사용하는 것이 적절하다.
- 제안한 저장스키마의 효율성을 평가하기 위해 GML 문서의 삽입시간, 저장 공간 사용량 및 엘리먼트당 검색시간을 측정하였다. 그 결과 GParent 방법이 삽입시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내었고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시하였다. 또한, 제안한 저장스키마에 적합한 GML 지원 하부 저장 관리자를 설계 및 구현하였다.
- 성능을 비교한 것이다. 데이터의 크기가 적은 경우, 즉 river.gml의 경우 Oracle 은 엘리먼트당 평균 검색시간이 약 68초가 요구되나, 본 논문에서 제시한 GML지원 하부 저장관리자는 약 0.1 초만을 요구한다. 또한 데이터의 크기가 큰 경우, 즉 farm.
- 각각의 Path 하나에 고유한 pathlD를 가지며 루트로부터 단계를 length로 표현하며 루트 자신은 length 1을 가진다. 둘째, Element 테이블은 XML 문서에서 모든 element와 path 와의 관계를 나타내는 테이블로 각각의 element는 고유한 DatalD 를 가지며, 어떤 path와 부합하는지 표현하기 위해 PathlD가있으며, 같은 path 일 경우 순위를 나타내는 order가 구성되어 있다. 셋째, Datapath 테이블은 부모-자식 엘리먼트와의 관계를 나타내는 테이블로 각각의 엘리먼트에 자식 엘리먼트가 존재할 때 Parent Data ID와 Child Data ID로 구성되어 있다.
- 이유는 Data-Element-DataPath 테이블의 전체 크기가 레코드수가 증가할수록 커지기 때문에, 저장 공간의 사용량이 많아진다. 따라서 GML 문서의 크기가 작다면 GParent #3 스키마가 효율적이며, GML 문서가 크다면 GParent #2 스키마를 사용하는 것이 효율적 이다.
- 1 초만을 요구한다. 따라서 데이터의 크기에 관계없이 GML지원 하부 저장 관리자는 Oracle 과 비교하여 약 700배 정도 성능이 우수함을 알 수 있다.
- 성능평가를 통해서 제안한 GParent 방법이 삽입 시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색 시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시한다. 또한 GML 지원 하부 저장 관리자의 성능 비교를 통해 GML 문서의 삽입과 검색 시간에 있어서 상용 DBMS인 Oracle보다 우수함을 나타낸다.
- 1 초만을 요구한다. 또한 데이터의 크기가 큰 경우, 즉 farm.gml의 경우 Oracle 은 엘리먼트당 평균 검색 시간이 약 67초가 요구되나, 본 논문에서 제시한 GML지원하부 저장 관리자는 약 0.1 초만을 요구한다. 따라서 데이터의 크기에 관계없이 GML지원 하부 저장 관리자는 Oracle 과 비교하여 약 700배 정도 성능이 우수함을 알 수 있다.
- 따라서 Element-Data 테이블 보다 Element-DataPath 테이블을 사용하는 것이 경제적이다. 문서의 Type어】 상관없이 GParent #3의 경우에는 가장 좋은 성능을 보이고 있으며, XParent와 비교해서 최대 약 45%, 최소 약 63%의 성능 향상을 보인다.
- 본 논문에서는 아울러 제안하는 저장 스키마를 바탕으로, GML 문서를 저장하기 위한 GML 지원 하부 저장 관리자를 설계 및 구현한다. 성능평가를 통해서 제안한 GParent 방법이 삽입 시간 및 저장 공간 사용량에서 기존의 XParent 방법보다 우수함을 나타내고, GML 문서의 삽입시간이 중요한 응용에는 GParent #2 저장 스키마가 최적이고, GML 문서의 검색 시간이 중요한 응용에는 GParent #3 저장 스키마가 우수함을 제시한다. 또한 GML 지원 하부 저장 관리자의 성능 비교를 통해 GML 문서의 삽입과 검색 시간에 있어서 상용 DBMS인 Oracle보다 우수함을 나타낸다.
- 아울러 GML 문서의 검색 시, 테이블 Manager API 를호출하여 검색을 수행한다. 셋째, Spatial Data Type API는 Spatial Data Type 모듈에 해당되며 Point(s), Polyline(s), Polygon(s) 클래스로 구성된다. 이 API< 통해서 모든 공간 데이터들에 대한 효율적인 관리를 수행한다.
- 3 초가 소요된다. 아울러 데이터의 크기가 큰 경우, 즉 faim.gml의 경우 Oracle 은 저장을 위해 약 2700 초가 소요되고, 본 논문에서 제시한 GML 지원 하부 저장 관리자는 약 88초가 소요된다. GML 문서의 삽입의 경우, 최소 약 30배에서 최대 약 90배 까지 Oracle 에 비하여 성능이 우수함을 알 수 있다.
- 같다. 첫째, GML문서는 공간 지리정보를 포함하여 다양한 형태로 변환 및 사용이 가능하다. 따라서 이미지 도형처리가 가능한 SVG(Scalable Vector Graphics)형태로 변환하고 필요한 데이터를 서버(Server)독립적으로 처리할 수 있어야 한다.
- 1 을 사용한다 아울러 구현된 시스템이 제공하는 API는 user interface API, 테이블 manger API, spatial data type API, RST API, Berkeley DB API 등이다. 첫째, user iterface API는 하위의 모든 API를 관리하며, 전체시스템의 최상위 interfaced 제공한다. 즉, user interface API를 통해서 GML 문서의 저장 /검색을 수행한다.
- GML 지원 하부 저장 관리자는 GML 문서의 효율적인 검색을 위하여 일반 텍스트 색인 및 공간 지리정보의 색인을 제공하며, 아울러 외부 API를 통해서 사용자가 쉽게 접근할 수 있는 환경을 제공하였다. 하부 저장 관리자의 효율성을 평가하기 위해, GML 문서의 삽입시간, 엘리먼트당 검색시간 및 Spatial Data에 대한 검색시간을 측정하여 기존 상용 DBMS 인 Oracle과 성능비교를 수행하였다, 그 결과 GML 지원 하부 저장 관리자는 모든 평가부분에서 Oracle보다 우수함을 나타내었다. 향후 연구로는 GML 지원 하부 저장 관리자를 in-memory 방식으로 발전시켜서, 보다 효율적인 GML 문서의 저장 및 검색을 통하여 전체적인 성능 향상을 도모하는 것이다.
후속연구
- 또한 주어진 지점에서 반경 10Km 내의 주유소를 검색하여 조건을 만족하는 GML 문서를 클라이언트(client)에 보내면, 클라이언트는 GML 문서를 사용하여 브라우징이 가능해야 하고 GML 문서를 원문 형식으로 보낼 수 있어야 한다. 둘째, 본 논문에서 적용하고자 하는 LBS나 텔레매틱스 응용에서는 새로운 도로나 POKpoint of interest) 가 생겼을 경우, 기존 문서나 저장 스키마에 대한 변경 없이 새로운 정보들만 추가적으로 저장하는 것이 요구된다. 또한 GML 문서 스키마의 국제 표준은 OGC(Open Geospatial Consortium)에서 지속적으로 진행 중이다.
- 하부 저장 관리자의 효율성을 평가하기 위해, GML 문서의 삽입시간, 엘리먼트당 검색시간 및 Spatial Data에 대한 검색시간을 측정하여 기존 상용 DBMS 인 Oracle과 성능비교를 수행하였다, 그 결과 GML 지원 하부 저장 관리자는 모든 평가부분에서 Oracle보다 우수함을 나타내었다. 향후 연구로는 GML 지원 하부 저장 관리자를 in-memory 방식으로 발전시켜서, 보다 효율적인 GML 문서의 저장 및 검색을 통하여 전체적인 성능 향상을 도모하는 것이다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.