A Database/Doctrine ORM design pattern to separate actual entities from metadata about them

I have a web application, and I need your help designing the best possible database/Doctrine ORM schema. My app is being built using Symfony and Doctrine. Let me give a scenario:

Suppose I have some business domain classes (Entities), Let's say:

 Tag, User, Domain and Post.

The user may publish a post, which belongs to 1,2 or 3 domains.
When the user adds a post, I want to suggest tags based on the domains he picked, the tags he had previously used, and raw tag weights.

Tag and Domain have many-to-many relationship, and a relationship between tag and domain has a weight.

So, I want to store meta data about those entities. For instance:

I want to assign each tag a weight, which is proportional to the times that tag was used by any user. I also want to store some data telling me the weight of the tag relative to each user (a kind of conditional probability, what is the probability of using tag B given user A). So I need another weight, which is user-tag-weight, calculated based on the usage count. Also, I need a weight on the relation between Domain and Tag.

All this weights will be learned and stored periodically, so I want to cache them in other tables.
Surely, it's not a good idea to store such data within the original entities, because it contrary to the principle of separating of concerns. Is not it?

One solution I thought of is creating three other entities:

ST_tag_weight, ST_tag_user_weight, and ST_tag_domain_weight;

to represent the total weight of a tag, the weight of the tag relative to a user, and the weight of the tag relative to domain, respectively.

I think it's a good design. But the problem with it is that I need to perform more database queries in order to obtain an entity with its metadata. Can anybody suggest a better DB/Doctrine ORM design, a kind of wrappers or something else?

Thanks in advance