关系理论如何以我在学习时关心的方式应用？
所以我正在学习麻省理工学院开放课程的离散数学课程，我想知道......我看到了关系和图表之间的联系，但还不足以“拥有”它。 我也在 SQL 中实现了一个简单的状态机，所以我很好地理解了图表，只是没有对关系和集合如何完全应用进行更严格的研究。 我是否应该遵循 Yegge 的思路，即浏览一下我不太容易理解的内容，然后在了解更多内容后再回来？ 我希望能够更好地分析我每天创建的图形结构（听起来很有趣），并且我想确保我现在不会传递有价值的信息。
（编辑：我想更好地了解不同的集合和关系属性如何与图论等事物相关，以及基本图论如何与集合/关系相关。）
有什么好的资源可以让我了解更多相关信息吗？ 我正在使用罗森的《离散数学及其应用》第五版，以防万一。
谢谢！
So I'm taking the Discrete Math course from MIT's OpenCourseWare and I'm wondering... I see the connection between relations and graphs but not enough to "own" it. I've implemented a simple state machine in SQL as well so I grok graphs pretty well, just not the more rigorous study of how relations and sets compeltely apply. Should I just be following the Yegge train of thought where I just glance over the stuff that I'm not grokking readily and come back when I've learned more? I'd like to be able to better analyze the graph structures I create on a day to day basis (sounds fun) and I want to make sure I'm not passing up valuable information right now.
(EDIT: I'd like to get a better idea of how the different set and relation properties relate to things like graph theory and how basic graph theory relates to sets/relations.)
Any good resources where I could learn more about this? I'm using the 5th edition of Discrete Mathematics and Its Applications by Rosen in case it matters.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
哇，4个小时了，没有回复； 我在学校也有过类似的经历，但只是学到了这些东西，然后才知道它有什么用处。 事实证明它非常有用，所以让我们看看这是否有帮助 -
数据库被正式定义为一组关系，但它也是一个图； 每个表是一个节点，每一列是与表连接的一个节点，每一行是与表连接的一个节点，每个字段是与行连接的节点，表之间的关系互连节点，外键关系互连行，查询约束（where 子句）和连接互连节点和节点集，等等。
SQL 查询可以被可视化为遍历由数据库关系和值形成的图并在每个节点上执行操作。 在查询执行规划器所做的事情的背后，它将查询分解为一组基本操作，并将它们排列在最有效的图中。
对数据库的更新也可以被视为图形操作，例如，更新订单行项目行中的数量会将更改传播到订单行中的总计，从而将更改传播到客户行中的 TotalSales，等等。
许多常见问题都会转化为图遍历问题。 曾经使用过 Google 地图来获取前往某个地方的路线吗？
wow, 4 hours and no answer; i had a similar experience in school but just learned the stuff and figured out what it was good for later. it turns out to be very useful, so let's see if this helps -
a database is formally defined as a set of relations, but it is also a graph; each table is a node, each column is a node connected to the table, each row is a node connected to the table, each field is a node connected to the row, relationships between tables interconnect nodes, foreign-key relationships interconnect rows, query constraints (where clauses) and joins interconnect nodes and sets of nodes, and so on.
An SQL query may be visualized as traversing the graph formed by the database relations and values and performing operations on each node. Under the hood that is what the query execution planner does, it breaks down the query into a set of fundamental operations and arranges them in a graph that is most efficient.
Updates to your database may also be thought of as graph operations, e.g. updating the quantity in an order line item row propagates the change to the the total in the order row, which propagates the change to the TotalSales in the Customer row, and so on.
many common problems devolve into graph-traversal problems. Ever used Google Maps to get directions to some place?