复杂层次结构建模
为了获得一些经验,我正在尝试制作一个可以回答有关动物王国的查询的专家系统。但是,我遇到了域建模问题。我最初认为动物王国的层次结构可以这样绘制,
-animal
-bird
-carnivore
-hawk
-herbivore
-bluejay
-mammals
-carnivores
-herbivores
我认为这样可以让我轻松地进行查询,例如“给我所有鸟类”,但说“给我所有食肉动物”会更昂贵,所以我将层次结构重写为看起来像:
-animal
-carnivore
-birds
-hawk
-mammals
-xyz
-herbivores
-birds
-bluejay
-mammals
但是现在查询“给我所有的鸟”会慢得多。
这当然是一个简单的例子,但它让我想到,在编写专家系统来回答上述查询的情况下,我真的不知道如何对本质上不那么严格分层的复杂关系进行建模。有向循环图似乎可以在数学上解决问题,但将其存储在关系数据库中并维护它(更新)对我来说似乎是一场噩梦。我想知道人们通常如何建模此类事物。解释或指向进一步阅读的资源的指针将是可以接受和赞赏的。
To gain some experience, I am trying to make an expert system that can answer queries about the animal kingdom. However, I have run into a problem modeling the domain. I originally considered the animal kingdom hierarchy to be drawn like
-animal
-bird
-carnivore
-hawk
-herbivore
-bluejay
-mammals
-carnivores
-herbivores
This I figured would allow me to make queries easily like "give me all birds", but would be much more expensive to say "give me all carnivores", so I rewrote the hierarchy to look like:
-animal
-carnivore
-birds
-hawk
-mammals
-xyz
-herbivores
-birds
-bluejay
-mammals
But now it will be much slower to query "give me all birds."
This is of course a simple example, but it got me thinking that I don't really know how to model complex relationships that are not so strictly hierarchical in nature in the context of writing an expert system to answer queries as stated above. A directed, cyclic graph seems like it could mathematically solve the problem, but storing this in a relational database and maintaining it (updates) would seem like a nightmare to me. I would like to know how people typically model such things. Explanations or pointers to resources to read further would be acceptable and appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您遇到了分类法的问题之一(事实上,远不是唯一的问题,甚至不是最糟糕的问题)。 多重继承作为一种概念工具,避免了分类法的许多问题 - 另一种说法是,分类法定义一棵树,基于 MI 的分类方案定义更通用的有向无环图,并且因此为您的建模提供了额外的自由度。
关系数据库方法会有所不同(不具体考虑层次结构或继承),但会得出与“多重继承”大致相同的概念结果:“类”(在林奈意义上的门/类/目/族/属/物种)是记录的一个领域,饮食(食肉动物、草食动物、杂食动物)是一个独特的领域——它们在概念化和搜索/检索方面都不会相互限制。
如果您被迫使用限制分类法的工具(又名树、单一继承等)进行建模,那么有一些技巧可以减轻它们造成的痛苦(在一定程度上),但它们取决于每个工具的具体情况限制,所以很难一概而论。
You've hit upon one of the problems with taxonomies (far from the only one, or even the worst one, in fact). Multiple Inheritance as a conceptual tool avoids many of the problems with taxonomies -- another way of putting it is, a taxonomy defines a tree, a MI-based classification scheme defines a more general directed acyclic graph, and therefore affords extra degrees of freedom in your modeling.
A relational database approach would be different (not thinking of hierarchy or inheritance specifically) but come to much the same conceptual results as "multiple inheritance": the "class" (in the Linnaeus sense of phylum/class/order/family/genus/species) is one field of the record, the diet (carnivore, herbivore, omnivore) a distinct one -- they don't constrain each other, neither in conceptualization nor in searches / retrieval.
If you're forced to model with tools that restrict you to taxonomies (AKA trees, single inheritance, &c), there are some tricks to ameliorate the pain they cause (to a modest degree), but they depend on each tool's specific restrictions, so it's hard to generalize.
如果您查看 MongoDB 手册页 使用多键模拟大量索引,你会看到MongoDB会让你在它的数据库中为每一种动物创建一个包含各种信息的“文档”:
然后你就可以查找通过您想要的属性的任意组合!
If you take a look at the MongoDB manual page on Using Multikeys to Simulate a Large Number of Indexes, you will see that MongoDB would let you create one "document" in its database for each animal that contains all sorts of information:
Then you can look up by any combination of attributes you want!
我使用 图数据库后端。我使用的示例最初来自 这个 基于 SQL 的示例。现在我什至不会尝试使用 SQL 来解决此类问题,这太痛苦了。 (免责声明:我是 Neo4j graphdb 团队的成员)
I wrote up a user roles example using a similar problem with a Graph database back-end. The example I use originally comes from this SQL based example. I wouldn't even try using SQL for this kind of problem nowadays, it's such a pain. (disclaimer: I'm on the Neo4j graphdb team)