I'm in the middle of moving right now, so as soon as i have the time, I'll definitely be making more.

In order to Help with the Database here are my thoughts

Grouping:

1. Individuals - Basic record
2. Families   - A Group of One or More Individuals. (Everyone Must Belong to a family)
3. Organizations or Companies - Groups of Families may or not belong (work for) to an Organization.

We will need to generate IndividualID, FamilyID and OrganizationID

Example:

XYZ Company, LLC (G54545658)

Kent Family  (F87985465)
Clark Kent (P369852)
Lois Lane ....

Jones Family
Sue Jones

Smith Family
Robert Smith
Sara Smith
Joel Smith
Sue Benaim

I would not separate companies from families. I would make a single "group" table with a "group type" and you can put people into whatever groups you want. Clark Kent can be part of the "Kent" family group, and the "Daily Planet" company group, as well as the "Superheroes" interest group.

Understood. I can see Clark in both groups(a Family and a Company)  but how do you establish Families under a Company? This requires a Family to be a Subgroup of a Company. Can it be done with only one Group table? Families need to be treated as Entities same as individuals if they are to be grouped under a Company.   So it is not just individuals in both groups. Families must also be grouped under a Company.  I will probably understand better once you do the Development. Cant wait. You are the boss...

In your POLL, One of the Key Items is DATABASE DESIGN.  
I believe this to be one of the  most important topics.
We saw some of this in your Associations database Design.
I Would welcome more design for different types of Databases.
Especially in the relationships Area.

I wouldn't group families under a company. I would group the individuals who make up the family under the company. This is why it makes more sense to have families and companies both designated as "groups." Of course, you can design your database however you want. This is the way I would go. Company and family are both arbitrary units of grouping. Separate them if you want, but then you get into other types of categories like clubs, memberships, etc. Unless there is a SIGNIFICANT amount of DIFFERENT information you need to gather for that data type, I'd put them together. Just like the helper table.

Eduardo  

DB design is pretty daunting at times for sure.  If you haven't already check out the Normalizing Data video.  A little more theory but definitely gets you thinking about how to relate data and break it out into the parts.

You might also want to check out the
Access Relationship Seminar.  In it Richard shows how to set up reverse or opposite relationships.  Adam is Eve's husband so Eve gets Adam as wife.
The Access Genealogy Seminar is another great one for breaking out and relating back together data.

Thank you Scott I will Do this.   I really need to get in right from the Get go.  I have studied carefully the relationships in ABCD database and in the Association Database.   In my case I keep thinking that my basic Entity is The Family that may have one or more Members. Also Families may Be Grouped in Companies.  I need to go into the database at any level: Individual, Family or Company.   I need to see how Richard proposes to do this.  I have been doing some testing with the ABCD. I will upload a Picture so you see what i Mean.

In order to keep FAMILY open at all times I create A FamilyID that is stored in the Entity Table. At the bottom of the Form I am dipalying the EntityID, EntityCode FamilyID and FamilyCode.   FamilyID and FamilyCode are the same for all Family Members and is the same the Primary members Code.