类型,属性,实例和值之间的关系

类型,属性,实例和值之间的关系

问题描述:

我正在开发一个通过Hibernate在数据库中存储数据的Java应用程序。

I'm developing an Java-application which stores its data via Hibernate in a database.

此应用程序的一个功能是定义类型等模板。用于重用。例如,该类型具有属性,您可以创建一个具有属性值的类型实例。

One feature of this application is to define templates like types, etc. for reuse. For instance the type has attributes and you can create instances of an type, which has values for the attributes.

问题是,我不知道如何确保只能为属性分配哪个类型定义的值。在我的解决方案中,有一个冗余导致问题,但我不知道如何删除它。

The problem is, that I don't know how to ensure that only values for attributes can assigned which the type defines. In my solution there is a redundancy which cause the problem, but I don't know how to remove it.

我当前(和有问题的)方法看起来像这样: / p>

My current (and problematic) approach looks like this:

@Entity
class Type
{
    @Id
    @Generated
    private Long id;

    @OneToMany(mappedBy="type")
    private List<Attribute> attributes;

    //...
}

@Entity
class Attribute
{
    @Id
    @Generated
    private Long id;

    @ManyToOne
    private Type type;

    //...
}

@Entity
class Instance
{
    @Id
    @Generated
    private Long id;

    @ManyToOne
    private Type type;

    //...
}

@Entity
class AttributeValue
{

    @Id
    @Embedded
    private ResourceAttributValueId id;

    @Column(name="val")
    private String value;

    //...
}

@Embeddable
public class ResourceAttributValueId implements Serializable
{
    @ManyToOne
    private ResourceStateImpl resource;

    @ManyToOne
    private ResourceAttributeImpl attribute;

    //...
}

有定义类型是冗余的:可以通过AttributeValue-> Attribute-> Type和AttributeValue-> Instance-> Type

There the definition of the type is redundant: Type can be reached via AttributeValue->Attribute->Type and AttributeValue->Instance->Type

访问类型另一个想法是使用类型+属性名称作为属性的id和实例+属性名称作为属性值的id,但这不能解决我的问题。

Another idea was to use type + attribute name as id of the attribute and instance + attribute name as id of the attribute value, but that doesn't solves my problem.

正确建模菱形依赖关系的关键是识别关系的用法:

The key for correctly modeling "diamond-shaped" dependencies like this is the usage of identifying relationships:

(我自由地重命名你的实体,我相信注意我们迁移

c>从钻石的顶部,两边,一直到底部,然后合并它在那里。因此,由于只有一个 ATTRIBUTE_INSTANCE.TYPE_ID 字段并且涉及两个FK,所以我们永远不能有一个属性类型的类型与实例的类型不同的属性实例。

Note how we migrate the TYPE_ID from the top of the diamond, down both sides, all the way to the bottom and then merge it there. So, since there is only one ATTRIBUTE_INSTANCE.TYPE_ID field and is involved in both FKs, we can never have an attribute instance whose attribute type's type differs from instance's type.

虽然这避免了不匹配属性,但它仍然不能确保属性实例的存在(如果您支持必需属性的概念) ,这在应用程序级最好地执行。理论上你可以使用循环延迟FK在数据库级别执行它,但并不是所有的DBMS都支持这一点,而且我怀疑它会很好地与ORM一起玩。

While this avoids "mismatched" attributes, it still doesn't ensure the presence of attribute instances (if you support the concept of "required attribute"), which is best enforced at the application level. Theoretically you could enforce it at the database level, using circular deferred FKs, but not all DBMSes support that, and I doubt it would play nicely with ORMs.

不幸的是,我Hibernate没有足够的经验来回答这是否可以映射到那里。

Unfortunately, I'm not experienced enough with Hibernate to answer whether this can be mapped there and how.

另请参见:

  • Choosing from multiple candidate keys
  • How to keep foreign key relations consistent in a "diamond-shaped" system of relationships