Question

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.

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;

    //...
}

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

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.

Answer 1

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

(I took a liberty of renaming your entities slightly, to what I believe is a more consistent naming scheme.)

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.

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.

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

See also:

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