本文分类应该在XML大类下，但CSDN目光短浅，只在网站制作技术和.NET下有XML分类。RDF与M$无任何关系，所以姑且放在网站制作技术-XML之下。
hax 译自 http://www-db.stanford.edu/~melnik/rdf/db.html
版权开放，欢迎转载 copyleft 2003, hax<hax@sjtu.edu.cn>.
========================
术语译名：
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
http://www.vldb.org/conf/2001/P149.pdf
存储RDF的数据库模式
-------------------
（最近的投稿在前）
清晰的模型（Explicit models）
-------------------------------
贡献者：Brian MacBride<bwm@hplb.hpl.hp.com>
日期：2000/5/11
摘要：本表示法清晰的表现模型并使用了视图
数据库模式（Oracle）和作者的描述：
sql = "CREATE TABLE RDFRESOURCE"
+ "("
+ "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,"
+ "ObjResource 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 RootModel"
+ " AS SELECT UNIQUE Id, Subject, Predicate,
ObjResource, ObjLiteral, Res, Asserted, Reified"
+ " FROM RDFModel, RDFStatement"
+ " WHERE RDFModel.Statement = RDFStatement.Id";
这创建一个人造的模型视图，包含数据库里所有的语句，无论语句在
哪一个“实际的”模型里。
视图被大量使用。每个模型都是一个视图，即一个在其他模型视图或
者RootModel视图之上的查询。因此每次Stanford API 调用一个创建
模型的操作——如某个查询，数据库里就创建一个新的视图。这必然
会导致一些对数据库的查询引擎来说异乎寻常的查询，而我就依靠数
据库的查询优化器来整理之。这里也存在因陈旧失效的视图被留在数
据库里而可能的应用崩溃问题。
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）有个问题。当前，模式像模型一样处理，并可以
输入到模式有效性校验器。没有尝试使用模式来定义一个更特殊的数
据库结构。
原贴：http://lists.w3.org/Archives/Public/www-rdf-interest/2000May/0094.html
