※ 역자주. 본 문서는 Jena2 시스템 레퍼런스의 데이터베이스 인터페이스 부분의 Overview의 번역문입니다. 짧은 영어실력으로 인해 오역된 부분이 있을 수 있습니다..^^
본 문서의 내용을 좀 더 쉽게 이해하시기 위해서는 Jena2의 데이터베이스 테이블 구조를 파악하시는게 도움이 됩니다. 간단히 Jena2는 표현테이블(statement table)과 시스템테이블(system table)로 나뉘며, 본문에 언급된 표현테이블은 전자에, long 리터럴 테이블과 long 리소스 테이블은 후자에 포함되어 있습니다.
Jena2 Database Interface - Database Layout
2004년 11월 2일(원문 작성일)
이 문서는 jena2 데이터베이스 스키마와 URI들과 리터럴 값들을 저장하는 것에 대한 좀 더 상세한 내용을 제공한다.
Overview - Denormalized Triple Store (비표준화 삼중 저장)
관계 데이터베이스 내에서 RDF 표현을 저장하기 위해 넓리 사용된 스키마는 triple store이다. 이러한 접근에서, 각각의 RDF 표현은 세개의 컬럼을 갖는 '표현' 테이블에 하나의 줄로 저장된다. 일반적으로, 네번째 컬럼은 리터럴 Object 혹은 URI Object들이 필요할 때 추가된다. 이 스키마의 공통된 변수는 표준화된 삼중 저장(normalized triple store)에 의해 더 적은 저장공간을 사용한다. 이 스키마는 리터럴 테이블과 리소스 테이블을 더한 표현 테이블을 사용한다.
리터럴 테이블은 모든 표현을 위한 리터럴들을 저장하고 리소스 테이블은 모든 표현들로 부터의 모든 리소스를 저장한다. 표현 테이블은 제목, 속성, object를 저장하지만, 값을 직접 저장하는 대신에, 리소스 테이블과 리터럴 테이블 안의 값에 대한 참조사항(reference)를 저장한다. 이 표준화된 스키마는 표준적인 삼중 저장(standard triple store) 접근보다 더 작은 공간을 사용한다. 리터럴 값과 리소스 URI는 단 한번만 저장되고, 표현내에 몇번 등장하든지 상관하지 않는다. 이 공간 저장은 비용이 초래됨에도 불구하고 제목, 속성, object 값의 표현을 위해 검색된 표현, 리터럴, 리소스 테이블의 3-way 조합을 요구한다. Jena1은 표준화된 삼중 저장 접근을 사욯했다.
Jena2는 표준 삼중 저장(standard triple store)과 표준화된 삼중 저장(normalized triple store)가 혼합된 비표준화된 삼중 저장 접근(denormalized triple store approach)을 이용하여 RDF 표현을 저장한다. 이 스키마는 전과 같이 표현 테이블, 리터럴 테이블, 리소스 테이블을 사용한다. 그럼에도 불구하고 표현 테이블은 값 자신이나 리터럴 테이블과 리소스 테이블들 안의 값에 대한 참조를 포함할 것이다. 'Short' 리터럴은 표현 테이블 내에 직접 저장되고, 'long' 리터럴은 리터럴 테이블 내에 저장된다. 비슷하게 short URI는 표현테이블에 직접 저장되고 long URI는 리소스 테이블에 저장된다. short과 long에 대한 길이의 시작점은 상대적이지만 기본적인 길이(default length)는 256이다(역자주 : 리터럴 혹은 URI의 길이가 256이하이면 short, 이상이면 long으로 jena2에서는 기본적으로 셋팅되어 있다는 표현인 듯).
Jena2 스키마에 대한 모티베이션(motivation)은 표준화된 접근(normalized approach)의 공간 저장과 표준 삼중 저장(standard triple store)의 검색 효율의 혼합이다. Jena2에서 long 리터럴과 object 값은 오직 한번만 저장된다. short 값들은 아마도 여러번 저장될 것이지만 그 값들은 길이가 짧다. 추가적인 저장공간은 마찬가지로 만족스럽게 요구된다.
더 많은 Jena2 검색 기능이 단지 표현 테이블의 접근에 의해 완료될 수 있다고 믿는다. 검색 기능은 제목, 속성, object에 적합한 값에 대한 모든 표현들을 반환한다. 그래서 값처럼 long(역자주 : long 리터럴, long URI를 이야기 하는 듯)은 short 리터럴이나 URI와 매치된다. 검색은 표현 테이블에서 단순한 SQL 선택만으로 실행될 수 있다. 반면에 만약 값이 long value와 매치된다면, 리터럴 혹은 리소스 테이블은 값의 매치의 식별을 위해 반드시 첫번째 검색된다. 그 후 값 자신보다 값 매치의 식별을 위해 표현 테이블이 검색된다.
space-time trade-off의 고려사항에서 Jena2 접근법은 응답시간내에 저장하기 위하여 여분의 저장공간을 사용한다. 반면에 사용자는 short과 long 값들의 기준을 설정할 수 있고, application의 필요에 따라 space-time trade-off를 조정할 수 있다. Jena2 저장 서브시스템에 대한 좀 더 자세한 내용은 Hewlett-Packard Laboratories Technical Report "Efficient RDF Storage and Retrieval in Jena2", HPL-2003-266에서 확인할 수 있다.
아래를 누르시면 원문을 보실 수 있습니다.
Jena2 Database Interface - Database Layout
2 November, 2004
This document provides some details on the Jena2 database schema and the encoding used to store URIs and literal values.
Overview - Denormalized Triple Store
A widely-used scheme for storing RDF statements in a relational database is the triple store. In this approach, each RDF statement is streod as a single row in a three column 'statement' table. Typically, a fourth column is added to indicate if the object is a literal or a URI. A common variation of this scheme which uses much less storage space is the normalized triple store approach. This scheme uses a statement table plus a literals table and a resources table.
The literals table stores the literals for all statements and the resources table stores all the resources from all the statements. The statement table stores the subject, predicate and object but instead of storing the values directly, it stores references to the values in the resources and literals tables. This normalized scheme uses less space than the standard triple store approach since a literal value or resource URI is only stored once, regardless of the number of times it occurs in statements. The space savings comes at a cost however since retrieving the subject, predicate and object values for a statement requires a 3-way join of the statement, literals and resources tables. Jena1 used a normalized triple store approach.
Jena2 stores RDF statements using a denormalized triple store approach which is a hybrid of the standard triple store and the normalized triple store. This scheme uses a statement table, a literals table and resources table as before. However, the statement table may contain either the values themselves or references to values in the literals and resources tables. 'Short' literals are stored directly in the statement table and 'long' literals are stored in the literals table. Similarly short URIs are stored directly in the statement table and long URIs are stored in the resources table. The length threshold for short vs. long is configurable but the default length is 256.
The motivation for the Jena2 schema is to combine the space savings of the normalized approach with the retrieval efficiency (i.e., no joins) of the standard triple store. In Jena2, long literal and object values are only stored once. Short values may be stored multiple times but, since they are short in length, the additional storage space required is deemed acceptable.
It is hoped that most Jena2 retrieval operations can be accomplished by accessing just the statement table. The retrieval operation returns all statements that match a value for subject, predicate and object. So long as the value to be matched is a short literal or URI, the retrieval can be performed with a simple SQL select on the statement table. However, if the match value is a long value, then the literals or resources tables must first be searched for the identifier of the matching value. Then, the statement table is searched for the identifier of the matching value rather than the value itself.
In terms of a space-time trade-off, the Jena2 approach uses extra storage space in order to save on response time. However, the user can configure the threshold for short vs. long values (see LongObjectLength in Options) and so adjust the space-time trade-off to the needs of the application. More details on the Jena2 storage subsystem are available in the Hewlett-Packard Laboratories Technical Report Efficient RDF Storage and Retrieval in Jena2, HPL-2003-266.