Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
636 views
in Technique[技术] by (71.8m points)

java - Relation between type, attribute, instance and value

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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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

enter image description here

(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:


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...