Â¥Ö÷

[ÇóÖú]Çë½Ì¹ØÓÚJena³Ö¾ÃÐÔ´æ´¢µÄÎÊÌ⣡ +----------------------+ | jena_g36t0_reif      | | jena_g36t1_stmt      | | jena_graph           | | jena_long_lit        | | jena_long_uri        | | jena_prefix          | | jena_sys_stmt        | +----------------------+ ÔÚÊý¾Ý¿âÖд´½¨ÁË7¸ö±í£¬ÕâЩ±í¾ßÌåÓÃÀ´´æ·ÅʲôµÄ£¿ÓÐЩ±íÊǿյġ£ ÄÄλ´óÏÀÄÜ·ñ°ïæ½âÊÍһϡ£Ð»Ð»£¡    Êղؠ  ·ÖÏí   ¶¥(0)

	µÚ2Â¥

ÕÒµ½ÁË

	µÚ3Â¥

Asserted Statement Table (Jena_GiTj_Stmt) These tables hold asserted (non-reified) statements for one or more graphs. The table name is generated and has the form Jena_GiTj_Stmt where i is a graph identifier and a j is a table counter for the graph, e.g., Jena_G1T1_Stmt. Reified Statement Table (Jena_GiTj_Reif) These tables hold reified statements for one or more graphs. The table name is generated and has the form Jena_GiTj_Reif where i is a graph identifier and a j is a table counter for the graph, e.g., Jena_G1T2_Reif. A row of the reified statement table, say         ex:subj, ex:prop, ex:obj, 1, ex:stmt, 'T' would represent the following four asserted statements in the graph (model) with identifier 1:         ex:stmt, rdf:Subject, ex:subj .         ex:stmt, rdf:Property, ex:prop .         ex:stmt, rdf:Object, ex:obj .         ex:stmt, rdf:Type, rdf:Statement . System Statement Table (Jena_Sys_Stmt) The system statement table is used to store system metadata for the Jena2 storage subsystem such as configuration parameters, table names for graphs, etc.. The metadata is expressed as RDF statements so this table looks very much like an asserted statement table. Long Literals Table (Jena_Long_Lit) The long literals table stores literals that are too long to store directly in a statement table. Each long literal is assigned a unique integer identifier and this identifier is used to reference the literal from a statement table. To support indexing of long literals, the first n characters of the long literal are stored in the Head column. The length of the head is configurable (see IndexKeyLength in Options). The remainder of the long literal is stored as a blob in the Tail column. A checksum is computed over the tail to distinguish long literals with the same Head. Long Resources Table (Jena_Long_URI) The long resources table stores URIs that are too long to store directly in a statement table. Each long URI is assigned a unique integer identifier and this identifier is used to reference the URI from a statement table. The columns of the long resources table are similar to those in the long literals table. However, the encoding of URIs is different from that of long literals. In particular, URIs may have prefixes. See the prefixes table and the encoding discussion, below. Prefixes Table (Jena_Prefix) URIs often have common prefixes (e.g., http://www.example.org/prop1, http://www.example.org/prop2). There can be substantial space savings if prefixes are stored just once. Jena2 will optionally store common URI prefixes in the prefixes table (see DoCompressURI in Options). This table is structurally similar to the long literals and long resources tables. Graph Table (Jena_Graph) The graph table stores the name and unique identifier for each user graph. An unnamed graph appears under the name DEFAULT. Lock Table (Jena_Mutex) The lock table is used internally by Jena2 to implement a critical section. It has no meaningful content. It the table exists, the database is locked for an internal critical section, e.g., creating a model. Normally, the lock is released at the end of the critical section by deleting the table. But, if a Jena application fails while in a critical section, i.e., while holding the lock, users may have to manually release the lock either by deleting the table or calling DriverRDB.unlockDB().