Entity Relationship Diagram Modifications

[twoski]

Homework Statement

Assume you are given the entity Person. This entity has 3 attributes: Name, Name of child, Name of parent.

Now, assume you want to modify your design of ”People” database above to include additional information about types of people such as sex, and people who are parents, etc. Use subclasses of people to represent these special types of people.

The Attempt at a Solution

There are 3 different entity sets we should start with: Person, Child and Parent. Person is the superclass which holds all generic information such as sex, name, age, etc.

Parent and Child should both have the "Is-a" relationship to Person, but we need to also show that a child can be the child of a person, and a parent can be the parent of a person. Should this be introduced as an attribute of the "is-a" relationship? Does one of the relationships take precedent?

We also note that Parents have the "grandparent of" relationship to children.

 

[DEvens]

Remember to solve the problem in "problem space" first. Then solve it in computer space. Does your problem require you to treat a person completely differently if they are a parent, a grand parent, a child, etc.? Or does it require the ability to treat a person differently in different contexts? So in one context a person is a parent, in another a child, in another a grand parent? And what happens if the context wants a parent but the person available has no children? Or if the context wants a grand parent, and the person available has children but no grand children?

Will your Person class include the "has a" for a list of parent persons and another list of child persons? That might make it simpler, but it will depend on the context of the full project. This scheme might have only one type of object, Person. There would not be a separate class for Parent and Child. Whether a Person was a Parent or a Child would depend on whether the appropriate list was empty or populated. You could then construct the family tree implicitly. If you do that then you need to decide if the information about parents and children is contained as pointers in the Person object, or as a separate family tree structure. And what validation rules will exist and be enforced by your database.

Alternatively, the requirements of Person might be very different in context to the requirements of Parent or Child. So the context might tell you that you need a derived class. Maybe there are situations in which you need a Child object but can't use a Person object. Or in which you need a Parent object but cannot use a Person object. This would depend on a lot of context that you may or may not have. Similarly you may need a special class for GrandParent, etc.

Or you may find that it is better to have some kind of data member in the class Person that indicates the jobs a Person object performs. Maybe flags for HasLivingParents, HasLivingChildren, etc. Or possibly NumberLivingParents, NumberChildren, etc.

You might get really fancy and include things like adoptive parents, foster parents, step parents, and so on.

So basically what you need to decide is: Whenever you need an object to describe a child, will a Person object be acceptable? When you need to describe a parent, will a Person object be acceptable? If it will, then make the Person class accommodate the job as a Child or Parent. If not, then make a new class that does the extra job.

Just for completeness, you should even consider the possibility that Child and Parent are not derived from Person. For example, Child-ness might be a bolt-on feature of Person. So Person might "have a" Child-ness. Or Person might "have a" Parent-ness. Or Child and Parent might be completely separate classes with very distinct purposes and behaviour. Again, this depends on the context. I suspect that in most situations involving people you probably don't want to do that. An example might be that your database specifically ignores (maybe for privacy reasons) the possibility that a Child of one Person is the Child of another Person in the database. It sounds very contrived even to me. But as an exercise you should stop and consider it, at least to reject it if it should be rejected.

 

[twoski]

The problem statement is exactly as posted... Quite vague and generic.

We are not coding anything based on this, merely designing an ER diagram.

It says we must use subclasses for the different "types" of people, ie. parents and children. So i think based on that we automatically need to have 3 entity sets: Person, Parent and Child. The relationships need to be based on this configuration so my first guess was to use "parent of" and "child of" relationships. Just not sure how that works when there's also applicable "is-a" relationships we can apply.