在关系数据库中表示与“多重继承”的层次关系

Question

I'm working on a python program that allows the user to categorise files by attaching 'tags' to them. These tags can stand in hierarchical relationships to one another. For example, the 'cat' tag can be categorized as a "descendant" of the 'mammal' tag. As a consequence, once a file is tagged as 'dog', it can be accessed via the 'mammal' tag as well.

These tags and their relationships to each other and to files will obviously need to be stored in a database, and I'm most familiar with relational databases.

I very much like the Modified Pre-order Tree Traversal method for storing trees in a relational database because it removes the need for recursion and requires fewer database queries.

However, I also want to facilitate tags with multiple parents. For example, 'dog' could be a child of 'mammal' and also of 'four-legged-thing' where not all four legged things are mammals or even animals (eg tables), and the 'mammal' and 'four-legged-thing' tags have no "common ancestor".

Does anyone know of a method of representing such relationships in a database while maintaining some of the advantages of the MPTT method?

Thanks for any help.

Answer 1

What you are describing is an acyclic directed graph, not a tree, so you can't use any of the sql "tree-storage" methods like MPTT. Here is an article that demonstrates an adjacency-list approach to this problem.

I highly recommend that you do not go down this path, however, not because of the difficulty of implementation, but because you will end up confusing and frustrating your users. In my experience users make poor use of complex ontological systems and are easily confused by them. Either use a flat "tag" namespace with no parent-child relationships, or use a tree arrangement with at most one parent per node.

But if you want to have a graph, he most straightforward way is to have a table like this:

CREATE TABLE tag_relationships (
    tag_child_id INTEGER NOT NULL REFERENCES tags (id) ON UPDATE CASCADE ON DELETE CASCADE,
    tag_parent_id INTEGER NOT NULL REFERENCES tags (id) ON UPDATE CASCADE ON DELETE CASCADE,
    PRIMARY KEY (tag_child_id, tag_parent_id)
);

You will probably not be able to avoid recursive queries. When you want to create a matching search, use the tags you have as search criteria and recursively add child tags until you have a complete tag list.

You will also have to be careful about creating cycles. When you add a relationship, you need to recursively visit parents and make sure you don't end up at the same node twice.

Something you can do to avoid recursive queries and help detect cycles is to denormalize your data a bit by making all relationships explicit for every node. What I mean is, suppose A is a child of B and C, and C is a child of D.

Instead of the minimum number of edges necessary to represent this fact:

tag_child_id  tag_parent_id
A             B
A             C
C             D

You would make all implicit relationships (ones you would have had to find via recursion) explicit:

A             B
A             C
A             D
C             D

Notice that I added (A, D) .