比較RDF和SQL資料

許多人問什麼可以用SPARQL來完成這個不能用SQL完成的事情，實際上他們關心RDF中可以做什麼，不能用關係資料庫完成。這兩種語言都使使用者能夠建立，組合和使用結構化資料。SQL通過訪問關係資料庫中的表來執行此操作，並且SPARQL通過訪問關聯資料的Web來完成此操作。（當然，SPARQL也可以用於訪問關係資料，但它被設計為合併不同的資料來源。）

關係資料由收集到表中的資料行（在正式關係文獻中也稱為“關係”）組成。表中的行符合稱為模式的集合資料型別和約束。稱為DDL（資料定義語言）的SQL子集聲明瞭該模式：

CREATE TABLE Person（
     ID INT，
     fname CHAR（10），
     addr INT，
     FOREIGN KEY（addr）REFERENCES Address（ID）
）;

CREATE TABLE地址（
     ID INT，
     城市CHAR（10），
     狀態CHAR（2）
）

這限制了Person某些資料庫中表中的行有三列 - “ID”，“fname”和“addr”，分別是整數，10個字元和另一個整數。它類似地定義一個Address表，並且要求表中“addr”列中的非NULL值對應於Person表中“ID”列的Address值。這允許資料庫捕獲在資料庫中表示的現實世界實體（事物）之間的關係。例如，下面的值表明，鮑勃住在馬薩諸塞州的劍橋，我們不知道蘇的生活在哪裡：

人

ID	fname	地址
7	鮑勃	18
8	起訴	空值

地址

ID	市	州
18	劍橋	嘛

發明了數字7,8和18，以識別它們之間的行並捕捉它們之間的聯絡。關於這些關係的SQL查詢通常不會提及具體的數字，但將重述關係的約束，即Person.addr=Address.ID

。這種相同的表示式可以捕獲不是內在關係的約束，例如，一個人的地址號與他們的鞋子大小相同。

RDF捕獲實體屬性和實體之間的關係，因為表單entity1的propertyA語句具有關係entity2。使用一種叫做烏龜的語言，我們可以說在馬薩諸塞州的劍橋有一個叫做“Bob”的地址，

<PersonA> a <Person>。
<AddressB> a <地址>。
<PersonA> <Person＃fname>“Bob”。
<地址B> <地址＃city>“劍橋”。
<PersonA> <Person＃addr> <AddressB>。
<AddressB> <Address＃state>“MA”。

還有另一個人，“蘇”，但我們不會對她的地址說什麼，因為我們不知道：

<PersonF> a <Person>。
<PersonF> <Person＃fname>“Sue”。

我們將RDF語句中的三個術語稱為主語，謂詞和物件。上述宣告中使用的術語是尖括號（<> s）中的相對URL，引號（“s”）中的文字和關鍵字“a”，只是用於標識“有型別”的URL的快捷方式關係。在RDF中沒有與SQL的NULL對應的概念，因為沒有與SQL的結構約束相對應的RDF要求，關係資料庫中的每一行必須符合相同的模式。一個斷言的物件，例如上面的<AddressB>可能是其他斷言的主題或物件。以這種方式，一組RDF語句連線起來以建立“圖形”（在數學意義上）。您會經常聽到“RDF圖”一詞。

<PersonC> <Person＃homeAddress> <AddressK>。
“PerconC”> <Person＃fname>“Bob”。
<AddressK> <地址＃所有者> <PersonC>。

上面的例子說明了RDF和關係資料之間的一些結構相似性和差異。核心的哲學差異在於RDF是一種後Web語言; 也就是說，它允許使用我們想要描述的實體的Web識別符號，以及我們用於描述它們的屬性和關係。如果我相信出版商不要騙我，我可以簡單地合併不同方面的資訊。這種信任的一個例子可以說是“我相信，只要這些方聲稱某人有一個< http://xmlns.com/foaf/0.1/givenName>，該值確實是該人的給定名稱？”

SPARQL和SQL簡介

專家們現在關於RDF和關係資料，我們現在可以檢查他們的查詢語言。獲取MA中每個人的地址的SQL查詢可能如下所示：

SELECT Person.fname，Address.city 
FROM Person，Address 
WHERE Person.addr = Address.ID 
AND Address.state =“MA”

從概念上講，我們從一組表中選擇屬性列表，以滿足某些約束條件。這些約束捕獲方案中隱含的關係Person.addr = Addresses.ID和選擇條件，例如Address.state =“MA”。

相同資料的SPARQL查詢可能看起來像

SELECT？name？city 
WHERE { 
     ？who <Person＃fname>？name; 
     <Person＃addr>？adr 
     ？adr <地址＃city>？city; 
     <地址＃州>“MA” 
}

無論更好還是更糟，SPARQL重用SQL使用者熟悉的關鍵詞：SELECT，FROM，WHERE，UNION，GROUP BY，HAVING和大多數聚合函式名稱。

看看上面的例子，我們看到SQL查詢的一般形式：

SELECT <attribute list> 
FROM <table list> 
WHERE <test expression>

測試表達式捕獲與特定查詢相關的行（行為“MA”狀態的行）和資料庫的結構（Person.addr引用Address.ID）。文獻和文獻傾向於避免使用歧義詞“選擇”，而是restriction用於選擇行和projection從這些行中選擇特定的列。查詢的結果是行列表，每列都有選擇的屬性列表。在課程頂部的示例資料庫上執行示例查詢會產生一個對應於“MA”中的一個人的解決方案：

fname	市
鮑勃	劍橋

上面的SPARQL查詢具有相似的結構：

SELECT <variable list> 
WHERE {<graph pattern>}

變數列表中的變數由圖形模式繫結。（記住，“圖”只是意味著三個是一組潛在的互連的語句。）圖形模式看起來像資料語句，但主題，謂詞或物件可能被替換為變數（以“？”開頭的術語） 。上面的模式找到與資料匹配的所有值，如name，？city，？who和？addr，僅顯示？name和？city：

？fname	？市
“鮑勃”	“劍橋”

查詢曾與變數的一個解決方案fname，並city繫結到文字“鮑勃”和“劍橋”。SPARQL解決方案集中的術語與SPARQL查詢或Turtle語句中的術語相同。請注意，SPARQL解決方案集中的列標題是出現在WHERE { <graph pattern> }SQL結果中的列標題是SQL模式中屬性（列）的名稱的變數。

NULL，OPTIONALS和LEFT OUTER JOIN

SQL使用令牌NULL來表示資料不可用或不適用。即使所選屬性為NULL，SELECT也匹配錶行。但是，如果沒有相應值的行，則連線約束通常會消除行。LEFT OUTER JOIN操作符執行常規（“內部”）連線，但如果不滿足連線約束，則不消除解決方案。以下查詢將選擇每個人的fname，如果可用，將選擇他們的城市：

SELECT Person.fname，Address.city 
FROM Person 
LEFT OUTER JOIN地址ON Person.addr = Address.ID 
WHERE Address.state =“MA”

fname	市
鮑勃	劍橋
起訴	NULL

SPARQL使用關鍵字OPTIONAL而不是LEFT OUTER JOIN，但效果類似：

SELECT？name？city 
WHERE { 
    ？who <Person＃fname>？name。
    OPTIONAL { 
         ？誰<Person＃addr>？adr。
         ？adr <地址＃city>？city; 
         <地址＃州>“MA” 
    } 
}

雖然連線語義在兩種語言之間是類似的，但在丟失資料的處理方面存在明顯的區別。缺少的資料根本不在RDF中表示。另外（並因此），如果有缺少的屬性，例如Sue的addr，SPARQL圖形模式將不會繫結。選擇每個人的姓名和地址記錄的識別符號的SPARQL查詢必須使addr屬性可選，以匹配Sue的記錄：

SELECT？name？city 
WHERE { 
    ？who <Person＃fname>？name。
    OPTIONAL {？who <Person＃addr>？adr} 
}

一個真正類似的SQL查詢必須防止繫結到NULL，即：

SELECT Person.fname，Person.addr 
FROM Person 
LEFT OUTER JOIN地址ON Person.addr = Address.ID 
WHERE Address.state =“MA”AND Person.addr IS NOT NULL

解決方案集合中的其他運算子

SPARQL和SQL具有非常相似的UNION和MINUS運算子，它們分別從解決方案集中新增和刪除解決方案。

因為SQL表的資料型別假定在所有行中都是一致的，所以必須注意對齊SELECT的資料型別。一些SQL資料庫強制執行此規則，讓使用者有一些有用的錯誤訊息來找到錯位。其他人也可以返回異構列，例如後面的​​行的值就像2012-05-28在一列浮點數。

網上查詢

SQL資料庫是資料的重新分配，一組表由資料行填充。SQL查詢在給定的資料庫上執行。SPARQL服務是否有預定的RDF資料庫是不同的。上面的示例查詢假設一組三元組可用於查詢，哪個可以從服務查詢已填充的資料庫。如果RDF資料庫預設為空，或者不包含查詢所需的資料，則需要指定載入該資料的位置。SPARQL重新使用SQL關鍵字“FROM”來標識需要載入以完成查詢的Web資源：

勘探

結合導航與探索在SPARQL中非常簡單。如果我想知道我的組織知道關於illudium phosdex的反應，我可以寫一個查詢，發現這些反應並探討他們的屬性：

SELECT？reaction？p？o 
WHERE { 
    ？compound ex：name“illudium phosdex”; 
    反應如：涉及化合物; 
    ？反應？五氧化二磷
}

在SQL中，這將像：

SELECT反應* 
FROM反應，化合物
WHERE reactions.compoundID = compounds.ID 
AND compounds.name =“illudium phosdex”

通用連結資料瀏覽器目前正在利用SPARQL來探索資料，並且可能導致一系列專門的介面，使知識使用者能夠理解和利用資訊資產。

聯邦

SPARQL的主要特徵可能會打動SQL使用者，這是能夠在不同的儲存庫之間聯合查詢。RDF理論為資料整合圖提供了基礎，而RDF工具則將該功能放在使用者手中，允許他們輕鬆檢索多個數據文件。整合大型資料庫也是微不足道的，而不是在本地檢索資料並進行合併，而是寫入SPARQL查詢，將查詢的部分委託給遠端查詢服務，例如本週的未發貨訂單：

SELECT？order？handler 
WHERE { 
     SERVICE <sales> { 
         ？order ex：soldBy？handler; 
         例如：？由於的dueDate 
         FILTER（由於>“2012-02-22”由於&& <“2012-02-29”？
     } {MINUS 
         服務<完成> {為了例如：？？運運} 
     } 
}

SQL沒有用於查詢聯合的標準系統。各種產品提供或多或少利用SQL語法管理對預先分配的資料庫集的訪問的工具。MySQL FROM指令可以加入執行在同一MySQL伺服器上的不同虛擬資料庫的資料，Oracle資料庫流和SQL Server整合服務使用該語法連線到通過某些手動配置對映到本地模式名稱的資料庫。

模式重用

大膽的說法是，SPARQL可以用於輕鬆整合資料，這要求資料當然在相交域中。為了使整合真正微不足道，它有助於以類似的方式表達資料。如果我們想將一個數據庫的某些化學物質的生理影響資訊與另一個數據庫的藥物成分連線在一起，那麼化學物質在兩個資料庫中的表現方式相同，這當然更容易。這似乎是一個很高的訂單，但SPARQL和RDF在網路上的基礎使得它很容易探索，擁抱和擴充套件現有的模式。如果合作精神可能不足以激勵人們使用相同的模式，我們仍然有懶惰來幫助我們打熵。

概要

介紹了關係型和RDF資料模型，並強調了它們之間的結構差異。這些差異在他們的查詢語言的能力上變得顯而易見。我們討論了遍及語義Web的重用和整合的文化，並提到SPARQL可用於訪問關係資料以及RDF。關於RDF和R2RML 的關係資料的直接對映：RDB到RDF對映語言的兩個最近的規範定義了這個過程。下一課將對比包含完全相同資訊的兩個資料庫的SPARQL和SQL查詢。