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.