Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to structure this Database?

Status
Not open for further replies.

SandiG

Technical User
Aug 31, 2003
3
US
I am setting up a database for our local Ronald McDonald House Charity to manage a list of contacts and donors, similar to a mailing list. The primary use of this database will be for mailing brochures, invitations, and other material about our fundraising events. The entities consist of Individuals, Households, and Businesses. All of the information fields are the same with each entity with the exception of Businesses that eliminates the first name field but contains an extra field for "Contact within Organization".
I have all the entities in one table using the LastName/Org field as a primary name identifier, and I have simplified the data entry process using a tabbed form to differentiate the Businesses fields. My basic reason for this is so that my overall report will list all entries alphabetically rather than by report section. In addition to the basic information, we have check boxes to catagorize each entry, and to link these entities to different funding campaigns (which can be several for each entity) as a means of filtering the list based upon the campaign we wish to promote.
Individuals and Businesses are fairly straight forward and can be done in one table, but with Households I have a dilemma. With multiple entities within a household who may individually have a connection to the charity, I need to uniquely identify each member of the household. I do not like the idea of entering each name separately in the table because of the pitfalls of data entry errors when last names and addresses are duplicated, etc. Should I create a table based upon a primary record which focuses on a "head of household" so to speak (the one side of the relationship), and then a linked table to contain any other members of the same household which contains only the information unique to that person (the many side of the relationship)? Or, should I create a table containing only the last name, address and pertinent data focused on "the location" (the one side), and use another table to link all the entities connected to that location (the many side)? My second question is how to encorporate both of these tables into a single report which would list out each separate entity for a complete mailing list, and then how to sort out all the records from both tables to compile the filtered mailing lists for our various campaigns. There are also times when I would want to combine the household names in an address for an invitation, like Mr. and Mrs. John Doe, or John and Mary Doe, rather than sending separate mailings to each individual within the household.
Any advice on the best way to structure this database would be most appreciated. I am familiar with creating complex forms for all this input, but I need a little help with the structure, and in developing the right reports to present the data.

And PS. 2 More questions: I have a form with a subform. When I open the form the focus is in the first field of the subform. I want the focus to be in the first field of the main form. How do I change that? Also, how do I replace the generic "999" with a default area code in a phone number mask?

Many thanks, Sandra
 
Sandra,
How thorough to you want to get?

One suggestion:

ContactsHeader Table--This has, at it's most basic, a ContactID, ContactName, and ContactType. This is the Header record.

Then the relationship to the 'detail' table should be defined as '1 to 1 to many' (as opposed to 1 to many), which means that there must be at least one detail, but could be many--a header can't exist without any detail.

This detail is the list of people at the Header's site. So, if ContactHeader could be:

ContactID = 1
ContactName=ABC Corp
ContactType=Company
ContactTotalDonations= 25000.00

ContactID = 2
ContactName=John Doe
ContactType=Individual
ContactTotalDonations= 500.00
Now, contact 2, john doe, must have a detail with (at the application level you an limit detail record to 1)

cdContactID=2
cdDetailSeq=1 'sequence, since we can have many here
cdFirstname=John
cdLastname=Doe
cdAddress=333 some street
cdComments=He'sTightwad

....and contact 1 might have dozens of these detail records.

Now, to get a bit more involved, the relationship could be many/many, ie:

Change the cdContactID in the Detail to it's own id totally independant from the Contacts header, and drop the sequence.

Then, logically 'in between' the Contacts and Detail is the Link table, with 2 fields: ContactID and DetailID. So now John Doe might be the president of ABC Company, and listed in that company's list of contacts, but he may just donate privately as well. So the Link table would look like:

ContactID DetailID
1 100 <--John Doe's DetailID
1 101 <--Some other guy's detail ID
2 100 <--John Doe again

...You can get much more in depth here--adding fields to the link table such as 'Donations with this Header contact', etc.

It's much more difficult to do subforms in that 'many-many' way, so you might want to go the simple '1 to 1-Many' way, in which case you'd have John Doe in the detail twice, but the application design would me much easier.
--jsteph
 
I don't think that I will need to link an individual to a business other than through a &quot;Contact&quot; field in the business information. If they also occur in the individuals table it is generally because the family is also involved with RMH, i.e. the wife donates also, or attends some of our functions.
Our main goal is to be able to sort the records based on campaign support to generate mailing lists, and a method to track donations from these donors by campaign.
The most simple approach will be the best considering the various staff and volunteers who could be working with this database.

Thanks,

Sandra
 
What jsteph has described IS the most simple approach.

First of all, you don't want to use the LastName/Org field as the primary key. You really should use an ID field (preferably an integer), the easiest is an autonumber field.

Secondly, since you have only slight differences in your information for each group (Individuals, Household, Business), you should only have ONE table to store address information. You should have at least two other tables, the HeaderTable that jsteph described that indicates what type of contact they are, and a detailTable which allows you to store all the individuals that are part of households and individuals that are just individuals. Then depending on what type of contact they are you can make decisions about which mail to be sent to them and how to be addressed.

HTH

Leslie
 
SandiG,

I'd say you're a decent distance from where you want to be before you start setting up tables (sorry!).

Try reading some stuff about building databases. There's a lot of great stuff out there. The one I usually recommend is Paul Litwin's &quot;Fundamentals of Relational Database Design.&quot; There's a copy on my site.

Fundamentally, if all of the fields except one or two are the same, that's a 100% solid indication that they should all be in the same table. If you need to keep track of different data sets in that same table, just make a field that you'll use to indicate Person, Company, or whatever else.

But do some reading. It's _really_ important to get the data structure right before going any further.

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks
Access Databases for Non-Profit Organizations

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.
 
Thanks Guys for all the advice. I was a PDox and AutoLisp programmer for many years, but it has been quite a while since I have done any &quot;real&quot; work. My SQL is a little rusty and Access is very different from DOS Paradox! I am working on a schema and will see where it goes...

Thanks,

SandiG
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top