 | |
Managing Genealogy Relationships in FMP 8.5
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Managing Genealogy Relationships in FMP 8.5 -
05-09-2007
, 03:56 PM
#2
| |||
| |||
|
|
I recently inherited a genealogy database with 27,000 names in it. The file was in GEDCOM format, so I tried lots of genealogy applications to see which one would work best for me. In the end they all had shortcomings and I decided to manage the records in FMP, especially since I prefer the freedom of manipulating records over the constraints of off-the-shelf designs. I read the GEDCOM manual, designed a DB that could handle the data, and converted the original file to FMP (8.5v1 running on Mac OS X 10.4.9). The question now is how to generate ancestor and descendant charts given the multiplicity of relationship types (of the familial kind). I've tried a few different methods, but they all seem to require gobs of relationships (of the database kind) based on proliferating match fields or redundant records that break all the rules of elegant design. Has anyone tackled genealogy or similar data structures and dealt with these issues? If so, I'd love to chat about it. The database spans 400 years and thousands of families (some as large as 16 children), including variants such as adoptions, divorces, multiple marriages, husbands marrying wives' sisters, etc. That said, I'd be happyif I could just generate a simple ancestor chart going back seven generations that wouldn't require a hundred and twenty-some match fields. Thanks in advance. -S. |
fields, but you will need a join table with lots of records. You'll
have a Persons table, obviously, and a Relationships table. The
Persons table will capture the info about that person. The
Relationship table is where you'll connect each Person to each other.
Each record in the Relationships table would be either a marriage or a
birth/adoption. Each of the latter would take up two records. Maybe
you need divorces in there too.
I'm imagining a family tree with lines between people. The lines are
what you'll capture in the Relationship table.
G
#3
| |||
| |||
|
|
On May 9, 2:56 pm, Sug <adam.suger... (AT) gmail (DOT) com> wrote: I recently inherited a genealogy database with 27,000 names in it. The file was in GEDCOM format, so I tried lots of genealogy applications to see which one would work best for me. In the end they all had shortcomings and I decided to manage the records in FMP, especially since I prefer the freedom of manipulating records over the constraints of off-the-shelf designs. I read the GEDCOM manual, designed a DB that could handle the data, and converted the original file to FMP (8.5v1 running on Mac OS X 10.4.9). The question now is how to generate ancestor and descendant charts given the multiplicity of relationship types (of the familial kind). I've tried a few different methods, but they all seem to require gobs of relationships (of the database kind) based on proliferating match fields or redundant records that break all the rules of elegant design. Has anyone tackled genealogy or similar data structures and dealt with these issues? If so, I'd love to chat about it. The database spans 400 years and thousands of families (some as large as 16 children), including variants such as adoptions, divorces, multiple marriages, husbands marrying wives' sisters, etc. That said, I'd be happyif I could just generate a simple ancestor chart going back seven generations that wouldn't require a hundred and twenty-some match fields. Thanks in advance. -S. |
trouble at all, since I know father and bother and can do the same for each
generation going backwards. (a pedigree chart) This one is pretty easy to
do, but I failed to create a descendants chart. Just because of the enormous
amount of information you want to display. Combined with the way you have to
count the generations. And you are dead right. When i simply start with my
earliest ancestor and start working my way up. After only 3 generations of 7
children I could end up with 7*7*7 children, who all may be married. So we
are talking 686 connections after 3 generations. I'm about 20 generations
down, so you can immagine how many data you will have to store and
categorize. I have not succeeded. I don't use this solution anymore, but
have bought a program. A really long time ago. It is DOS, but I still use
it. Did you try Brothers Keeper? I couldn't use it because it is too
American, but irt might just do it for you.
Keep well. Ursus
#4
| |||
| |||
|
#5
| |||
| |||
|
#6
| |||
| |||
|
|
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. |
saying is the relationships between uncle/nephew, second cousins once
removed etc etc are really just calculations of parent child
relationships and partnerships. They're just expressions of how far
back and to the side lies a common ancestor.
If you know two people have the same parents, you know they're
siblings. You don't need a 'sibling' join record. If you know three
generations of parent/child relationships you know who the aunts,
uncles and grandchildren are.
Moving from the theoretical to the practical, I'm still not sure if
there's a practical way to move forward with design. You could
construct a relationship graph that mimics a family tree, but that
would be unwieldy at the least. I think how the system would be used
would determine how to go forward.
It sounds like you're trying to chart and define two persons
relationship to one another. With a small graph, it may be possible
to scripting two persons relationship using sucessive GTRRs or maybe
by comparing Lists of relationship ids. On the fly might be harder,
with custom functions and calculations, but still possible.
I'm just throwing ideas out there, I guess I think it's an interesting
problem.
#7
| |||
| |||
|
|
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. |
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
#8
| |||
| |||
|
|
Not too encouraging, but I'm glad someone else has wrestled with the problem. I thought maybe I was overthinking it and the solution just staring me in the face. I haven't tried Brother's Keeper, but I'm working on a larger project that would combine the genealogy db with other features to create an archive for files (photos, docs, recordings, etc.). I'd like to use FMP as the backend with a PHP/Flash interface on the web that everyone in my family can access and contribute to. It appears that the other applications tend to generate charts dynamically rather than storing relationships, but I've found this sluggish in even the best programs and was hoping for a better solution. -S. |
only on Mac. It is excellent. Very versatile, compact, fast and
efficient.
See http://www.leisterpro.com/
--
For email, change <fake> to <earthlink>
Bill Collins
#9
| |||
| |||
|
|
In article <1178757205.472863.104... (AT) p77g2000hsh (DOT) googlegroups.com>, Sug <adam.suger... (AT) gmail (DOT) com> 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 |
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?
#10
| |||
| |||
|
|
On May 9, 7:46 pm, Greg Dember <g... (AT) artocratic (DOT) com> wrote: In article <1178757205.472863.104... (AT) p77g2000hsh (DOT) googlegroups.com>, Sug <adam.suger... (AT) gmail (DOT) com> 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
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.