Re: Managing Genealogy Relationships in FMP 8.5

On May 9, 10:35 pm, Sug <adam.suger...@xxxxxxxxx> wrote:
On May 9, 7:46 pm, Greg Dember <g...@xxxxxxxxxxxxxx> wrote:



In article <1178757205.472863.104...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,

Sug <adam.suger...@xxxxxxxxx> wrote:
Hi, G -

Thanks for your input. I do use join tables for certain aspects of
the database (the file has tables for managing photos, documents,
etc., and these can be stored in "albums" that are associated with
particular people, locations and events), but I don't think it's the
right solution for tracking familial relationships.

The problem with genealogy is that people are defined in relation to
other people, and those definitions change from person to person in
the database. What I mean is, if you have a product database with
27,000 items, the product type (aspirin, razor, toothpaste) is the
same no matter where you are in the store. But if you have a man in a
family tree, he's variously a brother, husband, grandfather, son,
first cousin twice removed, etc., depending on whose record you're
viewing him from.

That means that if you've got a hundred people in your family tree,
you'd need to generate a hundred join records for each individual to
specify the nature of the relationship, which means 10,000 new
records. With 27,000 people (all of them related, no matter how
distantly) that's 729,000,000 records. And every time you add a new
person, you have to add 27,000 join records to show how he's related
to everyone and another 27,000 records to show everyone how they're
related to him (note that kin relationships are often asymmetrical,
e.g., uncle/nephew; mother/daughter).

You see why I mentioned the redundancy problem in my first post. A
join table of this sort creates an unmanageable number of records for
each individual. Unless I'm not understanding you correctly.

OK, I've never done this either, but I'm going to jump in. I think
Grip's solution of having a join table where each record represents
either a marriage between two people or a parent-child relationship
between two people is less cumbersome than you realize.

You would not need records to indicate the grandparent relationships, or
the cousin or sibling relationships, or any of the more distant
relationships..... those can all be calculated just from the simple
marriage and parent-child pairings.

Think of an actual family tree diagram. You have people, and you have
lines connecting Husbands and Wives and Parents and Children. You don't
have lines connecting Uncles and Nephews. The Avuncular relationship is
inferred. The database can do the same thing.

Right?

Greg

Grip and Greg -

Truly appreciate your putting your heads to this. You are right that
all you need are marriage and birth records to trace all other
relationships in a family tree and that it doesn't require the
proliferation of records I mentioned last time. But it also doesn't
give you a graphical or textual representation of how person A is
related to person X. What it does give you is a way to get there --
but only if you want to move from record to record manually tracing
births and marriages till you arrive at the end of the maze.

Your suggestion is actually how the database is organized now: I have
a join table between People and Families in which each record notes
the person, the family and their role (husband, wife or child --
though it could just as easily be reduced to adult and child). This
is also, using a completely different file structure, how GEDCOM-based
applications track kinship -- so you're right about the fact that you
don't need anything more than that to plot the other relationships.

But in a sense that's the same as saying all you need to get from one
part of town to another is a list of each intersection: it's doable,
but a complete map is hella more efficient. And if you want the
complete map, you have to draw it, which is the problem we face here:
how to represent a family chart (even a limited one that shows direct
ancestors and descendants without brothers and cousins et al) without
making the solution unmanageable? And how to do this for every
record, so that the "self" at the center of the tree is different for
each record?

Does that make sense? I think Ursus is right that it's a crippling
problem from a Filemaker perspective. But perhaps there are some
geniuses out there who have tried it and come up with a solution?


You're not really asking for a map, you're asking for a map creation
program and that's what Greg and I have started you on. It's often
helpful to solve problems modularly. We got you past the data
structure part. You now understand how a genealogy tree can be
modeled on Filemaker.

You're also asking how to extract that information in a way that's
meaningful to you. I'd say scripts are the best way to do that here,
but exactly how and how well depends on what result you want. You
haven't given many details about that. Let's say a standard family
tree of just ancestors and descendents. (How big a page? How many
generations back? Connecting lines? Curling leaves?) I bet can get
'exploding' generations to line up reasonably well on a printed page
in a couple hours work.

Exactly how? Hmm. I'd start from the subject record and Go To
Related Record to grab the parents. Replace a Sort field to 1. GTRR
up again, Replace sort to 2 and so on. Then GTRR down from the
primary record, Replace Sort field to -1, etc etc. Find all records
with a value in the Sort field and sort descending. Filemaker isn't
great at graphical presentations, but I could rig up a layout showing
a tab delimited list of each generation in a Sub Summary part
(breaking on the Sort/Generation field with no body), the spacing of
the tabs determined by the generation. With some tweaking I think
that would be reasonably close to lining up properly in an 'exploding'
format. Print, clear all the Sort fields and repeat.

Again, I'm not saying Filemaker is the best way to do this. Genealogy
is a pretty fleshed out field, I'm sure there's several off-the-shelf
programs that can meet your needs, but you seem to have gotten hung up
on the idea of static modeling versus on-the-fly calculations. Google
Maps doesn't have a list of the directions from every point to every
other point and it just looks them up, rather it creates the
directions as necessary.

Grip

.

Relevant Pages

  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... but a complete map is hella more efficient. ... You now understand how a genealogy tree can be ... Replace a Sort field to 1. ...
    (comp.databases.filemaker)
  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... but a complete map is hella more efficient. ... Replace a Sort field to 1. ... Then GTRR down from the ...
    (comp.databases.filemaker)
  • Re: Managing Genealogy Relationships in FMP 8.5
    ... the database (the file has tables for managing photos, documents, ... family tree, he's variously a brother, husband, grandfather, son, ... Replace a Sort field to 1. ... Then GTRR down from the ...
    (comp.databases.filemaker)
  • Re: Designing a Data Base for School Exam Purposes
    ... You offered to take the OP's money in exchange for a "map". ... Providing Customers A Resource For Help With Access, Excel And Word ... design the table structure of your exam database. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: JTree & database: ID column ?
    ... > from database and for it I use ID1 column which is unique ... > and every number in a code represents the place in a parent node. ... And if you can construct a tree ... reverse-index is NOT an auto-inserted id value, although it has to be unique ...
    (comp.lang.java.gui)
Loading