关系数据库图数据库_什么是图数据库

最新推荐文章于 2023-11-24 21:51:05 发布

weixin_26721705

最新推荐文章于 2023-11-24 21:51:05 发布

阅读量608

点赞数

文章标签：数据库 mysql sql python java

原文链接：https://towardsdatascience.com/what-is-a-graph-database-249cd7fdf24d

版权

关系数据库图数据库

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, of the data stored in the database.

图数据库被描述为对图进行操作以及事物之间关系至关重要的数据库。图是一种结构，图数据库的基础图会映射存储在数据库中的数据的结构或架构。

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

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.等人，“关系数据库的图形分析”。