Much has been written about graph databases as a distinct type of database in the last few years and it is easy to forgive in believing the accompanying marketing material warranting differentiation of graph databases from any other database.

在過去的幾年中，已經有很多關於圖資料庫作為一種獨特型別的資料庫的文章，並且很容易原諒相信隨附的營銷材料可以保證圖資料庫與任何其他資料庫的區別。

So what does that marketing material say and how much should you give credit to?

那麼，營銷材料說了些什麼，您應該給多少功勞呢？

圖形資料庫和圖形 (Graph Databases and Graphs)

Graph databases are described as databases that operate over graphs and where relationships between things matter. A graph is a type of structure and the underlying graph of a graph database maps the structure, or schema

圖資料庫被描述為對圖進行操作以及事物之間關係至關重要的資料庫。 圖是一種結構，圖資料庫的基礎圖會對映儲存在資料庫中的資料的結構或架構。

The picture below is a graph model for a seat booking database solution for a cinema. We would use such a schema to book seats to watch a film in a particular session at that cinema. I believe it can be readily said that graph schemas are straight forward to look at.

下圖是電影院座位預訂資料庫解決方案的圖形模型。 我們將使用這種模式來預訂座位，以在該電影院的特定會話中觀看電影。 我相信可以很容易地說圖模式很容易研究。

Each line, or edge, with one or more arrows, represents a relationship or relation between what are called nodes or vertices and form what is called a directed graph. The type of model itself, has come to be known as a property graph schema. The property component of a property graph schema lends its name to where nodes and edges can have properties, as in Rating for the likes edge and Age for the Person node.

每條線或一條帶有一個或多個箭頭的邊表示代表節點或頂點之間的關係或關係，並形成稱為有向圖的關係。 模型本身的型別已被稱為屬性圖模式。 屬性圖模式的屬性元件將其名稱賦予節點和邊可以具有屬性的位置，如“喜歡邊的評分”和“人”節點的年齡。

NB In the graph theory of mathematics relationships need not be directed with one or more arrows, or have a reading (such as likes) so we take license here and have a bidirectional edge between Seat and Booking, because, let's face it, all relationships are bidirectional, and in this schema we use the bidirectional mapping to let us know that a Booking can be for many Seats and a Seat can be in many Bookings…information not generally captured in a property graph schema in this way because graph schemas in common use are left wanting when it comes to the finer semantics of the underlying model.

注意：在圖論中，數學關係不需要用一個或多個箭頭指向，也不需要閱讀(例如like )，因此我們在這裡獲得許可，並且在Seat和Booking之間具有雙向優勢，因為讓我們面對現實，所有關係是雙向的，在這種模式下，我們使用雙向對映來告知我們預訂可以用於多個席位，而一個席位可以位於多個預訂中……資訊通常不會以這種方式在屬性圖模式中捕獲，因為圖模式是通用的當涉及到基礎模型的更精細語義時，就沒有必要使用它了。

The edges with a large arrow and a small arrow let us know that the reading has a reciprocal reading stored in the schema in the software that this schema was generated on. E.g. Session is at Cinema may have a reciprocal reading Cinema hosts Session.

帶有大箭頭和小箭頭的邊緣使我們知道，該讀數在其生成該軟體的軟體中的模式中儲存有相互的讀數。 例如Session在Cinema可能互相閱讀Cinema主持人Session 。

Those relationships between nodes are what is used to navigate over the data in the database when querying the database. For instance, we might write a graph query that looks like the following:

節點之間的那些關係是查詢資料庫時用於瀏覽資料庫中資料的關係。 例如，我們可以編寫一個類似於以下內容的圖形查詢：

An advantage of viewing the schema of a database as a graph and querying the database as a graph is that the results of a query can also be viewed as a graph. In our example, the “Great Western Cinema” hosts a session that has a booking that has a seat that is in a row that has row number 1…viewed as ‘1 1’ below because the row is in cinema 1, which is the Great Western Cinema in our example database. Similarly that row has bookings for seats ‘A’ and ‘B’ in that row, and so forth.

將資料庫的模式檢視為圖形並將資料庫查詢為圖形的優點在於，查詢結果也可以被視為圖形。 在我們的示例中，“ Great Western Cinema”主持一個會話，該會話的預訂中的座位排在第1行…在下面被視為“ 1 1”，因為該行在電影院1中，即示例資料庫中的Great Western Cinema。 同樣，該行預訂該行中的座位“ A”和“ B”，依此類推。

挑戰“用途明確”的格言 (Challenging a ‘Purpose Built’ Adage)

Marketing material for graph databases generally claims that graph database are purpose built for graph processing. May be so, but in this article we challenge that ‘purpose built’ claim and ask the valid questions,

圖形資料庫的市場營銷材料通常聲稱圖形資料庫是專門為圖形處理而構建的。 可能是這樣，但是在本文中，我們對“有目的的”主張提出質疑，並提出有效的問題，

- “Are all databases graph databases?”; and - “Can all databases be queried with a graph query language?”

-“所有資料庫都是圖形資料庫嗎？”； 和-“是否可以使用圖形查詢語言查詢所有資料庫？”

That is, we ask, “What is a graph database?”

也就是說，我們問： “什麼是圖形資料庫？”

專用圖資料庫 (Dedicated Graph Databases)

Without doubt there are databases that are purpose built for graph processing. Let us call these ‘dedicated graph databases’. To my mind, these are the least interesting of databases.

毫無疑問，有專門用於圖形處理的資料庫。 讓我們稱這些為“專用圖資料庫”。 在我看來，這些是最不有趣的資料庫。

If all databases can be viewed as a graph database, why limit yourself to graph processing?

如果所有資料庫都可以視為圖形資料庫，為什麼還要限制自己進行圖形處理？

What other types of database processing is there?

還有哪些其他型別的資料庫處理？

We arrive at the crux of this article. Vendors of graph databases often distinguish their products from the primary selling type of database called a ‘relational database’, otherwise they would just be selling a database.

我們到達本文的重點。 圖形資料庫的供應商通常會將他們的產品與主要銷售型別的資料庫(稱為“關係資料庫”)區分開來，否則他們只會銷售資料庫。

什麼是關係資料庫？ (What is a Relational Database?)

As the name suggests, a relational database is a database in which relationships matter. Rather than write a treatise on what a relational database looks like, let's just view the same schema of our example as an entity relationship diagram (ERD), which is the type of schema used to view the relationships of a relational database.

顧名思義，關係資料庫是關係很重要的資料庫。 與其撰寫關於關係資料庫的外觀的論文，不如讓我們僅將示例示例與實體關係圖(ERD)視為同一模式，後者是用於檢視關係資料庫的關係的模式型別。

The animation below goes back and forth between a property graph schema (PGS) and an entity relationship diagram to show that we are speaking of the same schema, just viewed differently.

下面的動畫在屬性圖模式(PGS)和實體關係圖之間來回移動，以表明我們所說的是同一模式，只是檢視方式不同。

NB In mathematical terms, property graph schemas and entity relationship diagrams have a homomorphism that approaches an isomorphism. For all intents and purposes, their core structures are isomorphic.

NB在數學術語中，屬性圖形模式和實體關係圖有一個同態即接近一個同構。 出於所有目的和目的，它們的核心結構是同構的。

圖形查詢及其受歡迎的原因(Graph Queries and why they are popular)

Because graph databases readily store predicate information for each relationship in the schema of the database, the database can be queried in a language which exploits the predicate information and which makes for queries which are easy to read.

因為圖形資料庫很容易在資料庫的架構中儲存每個關係的謂詞資訊，所以可以使用利用謂詞資訊並使查詢易於閱讀的語言來查詢資料庫。

The following is an example of a graph query operating over our Cinema Bookings schema:

以下是在我們的Cinema Bookings模式上執行的圖形查詢的示例：

The beauty of graph queries is not only that they are easy to read, they are easy to write. The query above is written in Knowledge Language (www.factengine.ai).

圖查詢的優點不僅在於它們易於閱讀，而且易於編寫。 上面的查詢用知識語言(www.factengine.ai)編寫。

Contrast this to how you would write the same query in the Structured Query Language generally used for relational databases:

與此相比，您將如何使用通常用於關係資料庫的結構化查詢語言編寫相同的查詢：

SELECT Cinema.CinemaName,Row.Cinema_Id,Row.RowNr,Seat.Cinema_Id,Seat.RowNr,Seat.Letter,Booking.Person_Id,Booking.Film_Id,Booking.DateTime,Booking.Cinema_Id,Person.LoginNameFROM Cinema,Row,Seat,Booking,Person,Session,BookingHasSeatWHERE Row.Cinema_Id = Cinema.Cinema_IdAND Seat.Cinema_Id = Row.Cinema_IdAND Seat.RowNr = Row.RowNrAND BookingHasSeat.Person_Id = Booking.Person_IdAND BookingHasSeat.Film_Id = Booking.Film_IdAND BookingHasSeat.DateTime = Booking.DateTimeAND BookingHasSeat.CinemaId = Booking.Cinema_IdAND BookingHasSeat.RowNr = Seat.RowNrAND BookingHasSeat.Cinema_Id = Seat.Cinema_IdAND BookingHasSeat.Letter = Seat.LetterAND Booking.Person_Id = Person.Person_IdAND Booking.Film_Id = Session.Film_IdAND Booking.DateTime = Session.DateTimeAND Booking.Cinema_Id = Session.Cinema_IdAND Session.Cinema_Id = Cinema.Cinema_Id AND Person.LoginName = ‘Peter’

SELECT Cinema.CinemaName，Row.Cinema_Id，Row.RowNr，Seat.Cinema_Id，Seat.RowNr，Seat.Letter，Booking.Person_Id，Booking.Film_Id，Booking.DateTime，Booking.Cinema_Id，Person.LoginNameFROM Cinema，Row，Seat， Booking.Pine，Session，BookingHasSeatWHERE Row.Cinema_Id = Cinema.Cinema_IdAND Seat.Cinema_Id = Row.Cinema_IdAND Seat.RowNr = Row.RowNrAND BookingHasSeat.Person_Id = Booking.Person_IdAND BookingHasSeatseatSeatSeat.Film_Id = Booking.Film_ateDate =預訂。 .CinemaId = Booking.Cinema_IdAND BookingHasSeat.RowNr = Seat.RowNrAND BookingHasSeat.Cinema_Id = Seat.Cinema_IdAND BookingHasSeat.Letter = Seat.LetterAND Booking.Person_Id = Person.Person_IdAND Booking.Film_Id = Session.Film_IdAND Booking.Date Cinema_Id = Session.Cinema_IdAND Session.Cinema_Id = Cinema.Cinema_Id AND Person.LoginName ='Peter'

I propose that this is why graph databases and their query languages are popular. Viewing the result set as a graph is also convenient. Most graph databases will allow you to see the result in tabular format as well.

我建議這就是為什麼圖資料庫及其查詢語言很受歡迎的原因。 以圖形形式檢視結果集也很方便。 大多數圖形資料庫也允許您以表格格式檢視結果。

到現在為止還挺好(So far, so good)

We covered how graph databases map the schema of a database, and looked at how to query the data in a graph database. We have seen how data returned from a query over a graph database can be viewed in a tabular or graph fashion.

我們介紹了圖形資料庫如何對映資料庫的架構，並介紹瞭如何查詢圖形資料庫中的資料。 我們已經看到了如何以表格或圖形方式檢視通過圖形資料庫查詢返回的資料。

So are you ready to race out and buy a graph database?

那麼，您準備好競相購買圖形資料庫了嗎？

Maybe not so fast….

也許沒有那麼快…。

Here is the thing. The schema, query and results in this article were all ranging over a relational database. The FactEngine initiative puts paid to the notion that you need a dedicated graph database to achieve the qualities of a graph database. Indeed, research shows that many graph queries perform faster on relational databases [1].

這是東西。 本文中的模式，查詢和結果都涉及關係資料庫。 FactEngine計劃使您意識到需要專用的圖形資料庫來實現圖形資料庫的質量。 確實，研究表明，許多圖查詢在關係資料庫上的執行速度更快[1]。

多模型資料庫 (Multi-Model Databases)

I could now write an article then, “What is a relational database?”, but the converse is true…every relational database is a graph database. So this article will suffice if you like the look and feel of graphs and graph queries.

我現在可以寫一篇文章，“什麼是關係資料庫？”，但是反過來是正確的……每個關係資料庫都是圖資料庫。 因此，如果您喜歡圖和圖查詢的外觀，這篇文章就足夠了。

A database that supports relational and graph processing is called a multi-model database. The FactEngine thesis is that “All databases are multi-model…” and answering the question, “What is a graph database?” lands squarely with “All databases are graph databases, bar thinking different”.

支援關係和圖形處理的資料庫稱為多模型資料庫。 FactEngine的論點是“所有資料庫都是多模型… ”，並回答“什麼是圖形資料庫？”這一問題。 “所有資料庫都是圖形資料庫，直覺不同”。

This may be shocking to some, but it should not be controversial. With the right tools all databases are multi-model. That is, all databases can be viewed as a graph database and a relational database at the same time.

這可能使某些人感到震驚，但不應引起爭議。 使用正確的工具，所有資料庫都是多模型的。 也就是說，所有資料庫都可以同時被視為圖形資料庫和關係資料庫。

什麼是圖形資料庫？ (What is a graph database?)

You came here to find out what a graph database is, so let us define that realistically and to avoid confusion.

您來這裡是為了瞭解圖形資料庫是什麼，因此讓我們實際定義它並避免造成混淆。

“A graph database is any database over which a graph schema and graph queries can be written”. Simple.

“圖資料庫是可以在其上編寫圖模式和圖查詢的任何資料庫”。 簡單。

Dedicated graph databases may not be advantageous to your enterprise, business or personal application. A relational database may offer benefits peculiar to being a relational database and not covered by a dedicated graph database.

專用的圖形資料庫可能對您的企業，企業或個人應用程式不利。 關係資料庫可能會提供關係資料庫特有的好處，並且不會被專用圖形資料庫覆蓋。

As a consumer of product and information, I feel we need to be aware that most definitions of graph databases come from those who want to sell us a dedicated graph database. My job is to bring awareness that the definition of a graph database is what properties the database has, rather than who sells what to whom. Why race out and buy that graph database if you already have one?

作為產品和資訊的消費者，我覺得我們需要意識到，大多數圖形資料庫的定義都來自那些希望向我們出售專用圖形資料庫的人。 我的工作是使人們意識到，圖形資料庫的定義是資料庫具有的屬性，而不是誰向誰出售什麼。 如果您已經擁有一個圖形資料庫，為什麼還要競購該圖形資料庫？

Thank you for reading. As time permits I will write more on graph databases, relational databases and multi-model databases. I hope this has been helpful in understanding what a graph database is and what a dedicated graph database is.

感謝您的閱讀。 如果時間允許，我將在圖形資料庫，關係資料庫和多模型資料庫上撰寫更多文章。 我希望這有助於理解什麼是圖形資料庫以及什麼是專用圖形資料庫。

— — — — — — — — — — — — — — — — — — — — — — — — — — —

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

NB The original version of the model expressed in this article is copyright to Clifford Heath and Data Constellation, and is shared under the ActiveFacts project on GitHub: https://github.com/cjheath/activefacts. Examples and license found at: https://github.com/cjheath/activefacts-examples

注意：本文表達的模型的原始版本為Clifford Heath和Data Constellation的版權，並在GitHub上的ActiveFacts專案下共享： https : //github.com/cjheath/activefacts 。 示例和許可證位於： https : //github.com/cjheath/activefacts-examples

1. Rawlani, P. et al, “Graph analytics on relational databases”, Massachusetts Institute of Technology, https://dspace.mit.edu/handle/1721.1/100670, Accessed at 24/08/2020

   Rawlani，P.等人，“關係資料庫的圖形分析”，麻省理工學院， https： //dspace.mit.edu/handle/1721.1/100670，於24/08/2020訪問

Addendum: Please see also Jindal, A. et al, “Graph analytics on relational databases”, Massachusetts Institute of Technology.

附錄：另請參閱麻省理工學院Jindal，A.等人，“關係資料庫的圖形分析”。