在關聯式資料庫中儲存RDF (轉)

在關聯式資料庫中儲存RDF (轉)[@more@]

本文分類應該在大類下，但CSDN目光短淺，只在網站製作技術和下有XML分類。RDF與M$無任何關係，所以姑且放在網站製作技術-XML之下。

 

hax 譯自 .stanford.edu/~melnik/rdf/db.html" target=_blank>~melnik/rdf/db.html

版權開放，歡迎轉載 copyleft , hax.

========================
術語譯名：

RDF model  RDF模型
RDF statement  RDF語句
literal  文字常量
namespace  名稱空間

table  表
field  欄位
========================


本頁概述了當前在關係裡RDF的幾種方法，
*THIS IS A REQUEST FOR COMMENTS*，請將您的想法投稿
到 (www-rdf-interest@w3.org)！


動機（Motiviation）
-------------------

我們需要永久儲存和操作（大量的）RDF資料。一個可選的做法是使
用關聯式資料庫技術。這個方法的主要優點是它提供了一個可升級的
通用方案。


準則（Criteria）
----------------

這個不完全的列表指出了資料庫設計需要考慮的準則（無先後順序）：

  * 可伸縮性：我們能儲存和查詢超過十億(1B+)的triples嗎？
  * 查詢：支援哪一類的查詢？它們可以被容易的公式化表述和處理嗎？
  * ：查詢的耗費多大？交付查詢結果的耗費呢？
  * ：我們能如何處理refication？
  * 組織：怎樣在儲存資料之上建立關聯？我們能對RDF models進行
  易分辨的混合並仍能確定triples來自何處嗎？

以下的提議方案從不同方面滿足上述準則。本頁的維護者對可伸縮性
問題尤感興趣。請將反映你需求的準則提交給我！


出版物（Publications）
----------------------

下面這個論文討論了以垂直模式儲存和查詢稀疏的關係表，這與一些
提議方案的精神非常相似：

R. Agrawal, A. Somani, and Y. Xu: Storage and Querying of
E-Commerce Data, Proc. VLDB 2001, Roma, Italy, available as



儲存RDF的資料庫模式
-------------------

（最近的投稿在前）

清晰的模型（Explicit models）
-------------------------------

貢獻者：Brian MacBr

日期：2000/5/11

摘要：本表示法清晰的表現模型並使用了檢視

資料庫模式（）和作者的描述：

  = "CREATE TABLE RDFRE"
  + "("
  +  "Id INTEGER not null primary key,"
  +  "NS INTEGER not null,"
  +  "RoName varchar(255)"
  + ")";

資源表儲存所有的資源，Id是內部的識別符號欄位，NS是個指標，指向
namespace表的條目以給出資源的名稱空間。RoName應該叫做‘localname’，
是Qname的區域性命名部分。


  sql = "CREATE TABLE RDFNameSpace"
  + "("
  +  "Id INTEGER not null primary key,"
  +  "NsName varchar(255)"
  + ")";

名稱空間表。


  sql = "CREATE TABLE RDFLiteral"
  + "("
  +  "Id INTEGER not null primary key,"
  +  "VAL varchar (4000)"
  + ")";

literals [hax注：可譯作文字常量] 表。 4000字元的限制對當前目
標來說足夠。[hax注：Oralce的可變字串的上限是4000位元組]
 

  sql = "CREATE TABLE RDFStatement"
  + "("
  +  "Id INTEGER not null primary key,"
  +  "Subject INTEGER not null,"
  +  "Predicate INTEGER not null,"
  +  "Obsource INTEGER not null,"
  +  "ObjLiteral INTEGER not null,"
  +  "Res CHAR(1) not null"
  + ")";

Statement [hax注：可譯作語句或陳述] 表。最初是單個欄位，
可以有一個物件或者文字常量的ID。使用一個複雜的JOIN來列
舉陳述，但並不如期望的執行。可能是我對SQL不足。而這個工
作和感覺更“正確”。Res是一個標誌以說明物件是資源還是文字常
量。


  sql = "CREATE TABLE RDFModel"
  + "("
  +  "ModelId INTEGER not null,"
  +  "Statement INTEGER not null,"
  +  "Asserted CHAR(1) not null,"
  +  "Reified CHAR(1) not null,"
  +  "primary key(ModelId, Statement)"
  + ")";

資料庫可以處理多個models [hax注：可譯作模型]。這個表儲存了每
個模型的語句列表。最初該表由語句表組合，但當集合操作時不
能工作。

Asserted標誌說明該語句用於給模型作斷言。
Reified標誌說明該模型用於使模型具體化。
後者是留給未來實現的掛鉤（hook）。具體化（Reification）沒有
被實現，因此這個方法是未經測試的。

每個模型都是資源，並在資源表裡有一個記錄。ModelId欄位是該資
源的識別符號。這樣，就可以寫關於某個模型的語句。這裡有一個模型
的類，這樣可以在確認模型有效性時列出需要被載入的模式（schemas）。


  sql = "CREATE OR REPLACE VIEW Model"
  +  " AS UNIQUE Id, Subject, Predicate,
  ObjResource, ObjLiteral, Res, Asserted, Reified"
  +  " FROM RDFModel, RDFStatement"
  +  " WHERE RDFModel.Statement = RDFStatement.Id";

這建立一個人造的模型檢視，包含資料庫裡所有的語句，無論語句在
哪一個“實際的”模型裡。

檢視被大量使用。每個模型都是一個檢視，即一個在其他模型檢視或
者RootModel檢視之上的查詢。因此每次Stanford 一個建立
模型的操作——如某個查詢，資料庫裡就建立一個新的檢視。這必然
會導致一些對資料庫的查詢引擎來說異乎尋常的查詢，而我就依靠數
據庫的查詢最佳化器來整理之。這裡也存在因陳舊失效的檢視被留在數
據庫裡而可能的應用崩潰問題。


  sql = "CREATE TABLE RDFKEYS"
  + "("
  +  "TableName char(10) not null primary key,"
  +  "Key INTEGER not null"
  + ")";
  sql = "INSERT INTO RDFKEYS (TableName, Key)
  VALUES('Resource', 0)";
  sql = "INSERT INTO RDFKEYS (TableName, Key)
  VALUES('NameSpace', 0)";

一個鍵發生表。可能可以使用序列器（sequencer） [hax注：Oracle
使用序列產生自動遞增或迴圈的數字]，但看起來有點資料庫特性相
關，至少不是我一開始想要的，儘管真的只需要一個發生器。


關於模式（schemas）有個問題。當前，模式像模型一樣處理，並可以
輸入到模式有效性校驗器。沒有嘗試使用模式來定義一個更特殊的數
據庫結構。


原貼：