[FIXED] Confused with potential is a and has a relationship

Issue

I am trying to configure a new database design seeing as we have decided to make the move to Hibernate. Previously in my Java code I had the following three classes

Super class

public abstract class Card {
    
    private String firstname;
    private String lastname;
    private String email;
    ...
}

A card sub class

public class ContactCard extends Card{
    private String variable1;
    private String variable2;
    private String variable3;

    public ContactCard(){

        super(firstname, lastname, email);
        ...
    }
}

And a few others to follow. This seemed to work fine. However I am starting to get a little confused. Here we have the subclasses in is a relationships, some card is a card. I am failing to map this in to database tables though.

For example, to incorporate the process of a card table in the database I could have a table for each sub class type, and inside this table i could have an id which references a card table (which is generated when a user registers). But, this now means that in my database I have transformed the is a relationship in to has a? The subclass now has a card rather than is a card.

I am confused and hope someone can clear things up for me.

Thanks

Solution

The confusion stems from the fact that the ORM has to translate objects to relations and vice versa. is a is a relation that means a subclass in OOP terms, a class that extends the base class. However, in RDBMS terms you have relations (or tables, the two mean the same thing) and records/entities that belong to said relations.

Now, if you have a table that is mapped to your Card class, then the subclass (I will call it MyCard for now) cannot be inherited per se in your RDBMS, since there is no inheritance. So, instead of inheriting the record, some convention is needed in order to represent that concept instead.

If MyCard has a foreign key mapped to Card, then this means that there is a many-to-one relation (as long as Card does not have a foreign key as well, in which case there would be a one-to-one relation).

If I would have to create an is a relation in the table, then the first (but not best) idea I would come up with would be to have a foreign key both in the Card and the MyCard relation towards each-other, because this would technically force that the relation between the two tables is not being duplicated. However, what if you have a MyCard base relation and some other possible relations, like MyCard1, MyCard2, ... MyCard999 and your Card does not necessarily have matches to each of them, then your Card relation would be filled with 999 fields that rarely have values.

Even if there is a single MyCard relation, having a foreign key from Card to it is unnecessary, because, if we are consistently using it as an is a relation, then it will be an is a relation rather than a has a, even if there is no technical difference between the two representations.

As a result, it is better to only create a foreign key from MyCard to Card only, because then

• your schema is as simple as possible
• your schema is as easy to be maintained as possible

So, how can we represent this in OOP?

We can have a field in MyCard that represents the Card.

In short: this looks like an is a relation, but since it is consistently used as a has a relation, it is essentially a has a relation.

Answered By - Lajos Arpad
Answer Checked By - Willingham (JavaFixing Volunteer)