Re: Entity Overlap and Relationships

Mikito Harakiri wrote:
> Bob Badour wrote:
>

>>How does your proposed design capture 'friend' ? Even the obviously
>>incomplete requirements included that.

Looks like hey left out what is for me the most interesting relation, cousin. There's an algorithm or two for figuring them out (perhaps on wikipedia), whether they are first or second cousins, etc., how many times they are 'removed' and interesting that 'uncle' is a special case of cousin. In a genealogy db one might include acquaintances too. Eg., I would have had a cousin but the baby and mother died during an abortion. I know who the mother was but not the father, only a list of possible fathers. Some people hold a funeral for a stillborn baby, so a db requirement might say that the baby should be recorded in the People relation and genealogy fans certainly want to know about it.

I haven't got far with this, but it was clear early on that mikito is right about having a People relation, eg. consider whether a query for 'stepfather of x' is a requirement. When I tried to make a family history (which admittedly is a little beyond just genealogy) it was surprising how many problems came up beyond ones that involved closures, eg., multiple birthdates for the same person or partial birthdates, plus all kinds of security questions if strangers are allowed to view the db.

I was annoyed to find that many, perhaps most of the people who are into genealogy use a hierarchical exchange format - I think one of the Mormon churches invented it, lots of alternate 'estimated' date fields and such. Seems the relational people haven't dug into this area much.  From what I've seen, nobody has come up with a set of general requirements for a genealogy db that would satisfy me and even if they did I think implementing all of them would be quite a challenge for current sql products.

p Received on Fri Apr 21 2006 - 19:11:24 CEST