A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Church Database



 
 
Thread Tools Display Modes
  #1  
Old February 24th, 2010, 08:17 PM posted to microsoft.public.access.tablesdbdesign
MissThing
external usenet poster
 
Posts: 2
Default Church Database

Trying to put together a simple database for our church directory and
records. We need contact info as well as DOB and group involvement etc. Make
directories, labels, email groups and basic reports. Which I had no problems
with. What I am having issues with is the family relationship thing. We
often need to do mailings per household as well as individuals. What is the
best way to "group" my families. And how should they be entered? I thought
making a check box to designate a "head of household" and when entering
choose a family. Or have a seperate form for "families" THEN enter
individuals designateting them to that family. I don't want to have a whole
lot of tables and things. I really want this as simple as possible with as
little things that could get messed up down the road.

also this will hold our deceased records. Should we have a whole seperate
DB for that? or just have it together. This is not the main issue though and
can handle that at some other time. Right now I just have deceased as a
option under status.

Thank you so much for your time!

Lyndsey

I should mention I'v just altered the sample contacts template.

  #2  
Old February 24th, 2010, 08:43 PM posted to microsoft.public.access.tablesdbdesign
Steve[_77_]
external usenet poster
 
Posts: 1,017
Default Church Database

Lyndsey,

I would like to offer to create this database for you. The database would
include your deceased records. I could provide you the database quickly and
you could have it up and running in a short time. There would be a modest
fee for the database. If you are interested, contact me.

Steve



"MissThing" wrote in message
...
Trying to put together a simple database for our church directory and
records. We need contact info as well as DOB and group involvement etc.
Make
directories, labels, email groups and basic reports. Which I had no
problems
with. What I am having issues with is the family relationship thing. We
often need to do mailings per household as well as individuals. What is
the
best way to "group" my families. And how should they be entered? I
thought
making a check box to designate a "head of household" and when entering
choose a family. Or have a seperate form for "families" THEN enter
individuals designateting them to that family. I don't want to have a
whole
lot of tables and things. I really want this as simple as possible with
as
little things that could get messed up down the road.

also this will hold our deceased records. Should we have a whole seperate
DB for that? or just have it together. This is not the main issue though
and
can handle that at some other time. Right now I just have deceased as a
option under status.

Thank you so much for your time!

Lyndsey

I should mention I'v just altered the sample contacts template.



  #3  
Old February 24th, 2010, 08:52 PM posted to microsoft.public.access.tablesdbdesign
John... Visio MVP
external usenet poster
 
Posts: 900
Default Church Database - stevie pimps agan

"Steve" wrote in message
...
Lyndsey,

I would like to offer to create this database for you. The database would
include your deceased records. I could provide you the database quickly
and you could have it up and running in a short time. There would be a
modest fee for the database. If you are interested, contact me.

Steve



stevie you have no shame you will pimp your questionable services to anyone.

Stevie is our own personal pet troll who is the only one who does not
understand the concept of FREE peer to peer support!
He offers questionable results at unreasonable prices.

These newsgroups are provided by Microsoft for FREE peer to peer support.
There are many highly qualified individuals who gladly help for free. Stevie
is not one of them, but he is the only one who just does not get the idea of
"FREE" support. He offers questionable results at unreasonable prices. If he
was any good, the "thousands" of people he claims to have helped would be
flooding him with work, but there appears to be a continuous drought and he
needs to constantly grovel for work.

Please do not feed the trolls.

John... Visio MVP



  #4  
Old February 25th, 2010, 12:28 AM posted to microsoft.public.access.tablesdbdesign
Dennis
external usenet poster
 
Posts: 1,222
Default Church Database

Lyndsey,

Allen Browne has an article that discusses your issues. I don't know if it
will answer your question or not. Here is the link:

http://allenbrowne.com/AppHuman.html

I've toyed with this idea also for one of my membership databases, but have
not done anything yet.

My thoughts, for what they are worth:

tblFamily Table - like Allen's tblGroup table.
keyed by FamilyNo - Automatic number field
Flds: Family Name
Address
City
St
Name
Head of Household Member Id (foreign key to the tblMember
table).

tblMember Table - Like Allen's tblClient table.
Key: MemberNo - Automatic number field
Flds: Family No
Title (Mr, Ms, Mr & Mrs, etc.)
First Name
Middle Name
Last Name (of just one field for name)
Relation (Head of household, father, mother, son, daughter, etc)
Birthday
Date of Death (if this field is not 0, then person is deceased)
(no use to have a yes/no field AND a date of
death field.
Notes


As for the entry screen:

I've asked the same question on this forum as you did about the data entry
screen and I've not received a good answer.

You could do two separate data entry forms / screen, but that is a data
entry paid.

I think a better option would be to create a Family Form that has a member
sub-form on it.

The top havel of the Family form would allow the user to enter the "Family"
house information. This form would have the tblFamily as it RowSource.

The bottom half of the form would be the Member sub-file form where you
would enter the individual family members. This sub-form would retrieve the
family number from the master form. When the head of house hold member is
entered, this sub-form would set a "head of house hold member id" variable in
the family form

This design is not as flexible as Allen's design because it does not allow
one person to be a member of multiple family as Allen's design does.
However, Allen's design is a bit more work to implement.

As for the deceased information, I would include that information on the
member record just for simplicity.

Which sample template did you modify - Microsoft's?

I would love for other people to add their opinions as I would love to have
an answer to these questions.


If you have more detailed questions, please post them and I will try to
answer them. I have a vested interest in this only because I have the same
question.

If you have problems setting up the form and sub-form (which I did when I
first learned about sub-forms), please post to this question. I've had a LOT
of help for this forum whilel I was working with my software for a local
charity, so I'm happy to help you.


Good luck.

Dennis
  #5  
Old February 25th, 2010, 12:29 AM posted to microsoft.public.access.tablesdbdesign
Stop$teve
external usenet poster
 
Posts: 76
Default Church Database


"Steve" schreef in bericht ...
Lyndsey,

I would like to offer to create this database for you. The database would include your deceased records. I could provide you the
database quickly and you could have it up and running in a short time. There would be a modest fee for the database. If you are
interested, contact me.


What are you doing $teve. ???
Almost everybody here hates you for your advertising...

Desperately seeking work ??
Get lost $teve. Go away... far away....

Again... Get lost $teve. Go away... far away....
No-one wants you here... no-one needs you here...

This newsgroup is meant for FREE help..
No-one wants you here... no-one needs you here...
OP look at http://home.tiscali.nl/arracom/whoissteve.html
(Website has been updated and has a new 'look'... we have passed 11.500 pageloads... it's a shame !!)

Arno R



  #6  
Old February 25th, 2010, 11:44 PM posted to microsoft.public.access.tablesdbdesign
Fred
external usenet poster
 
Posts: 1,451
Default Church Database

I've databased alot of organizations and wrestled with your issue.

IMHO

The Allen Browne approach referenced by Dennis is very sophisticated,
versatile, powerful & abstract. (that's what you get from someone who is
one of the smartest on the planet at this) Those are 4 things that you might
want to avoid unless you needed them, which you probably don't.

So then the question becomes whether you need a full "two tier" system (with
Families and People both being entities) vs. just "stretching" a one "tier"
system (people). You probably need a two tier system.

And so basically that means do what Dennis said. Except that I think he
misread yo on one point....I think you intended your "head of household"
idea as an alternate to the two tier method.....and so now you don't need it
and he was trying to add it. (or maybe I misread you :-) )

So, recapping, (change all names as desired) make a "Families" table, (PK =
autonumber "FamilyID" field. Make a "People" table with an integer (FK)
"FamilyID" field. Link the 2 "FamilyID" fields.

You main data entry form will be a "Families" form with a datasheet style
"People" subform.

Every person belongs to a family, even if a "Family of One"

So, to enter a person, go to that main form, find or enter their family,
then enter the person in the Person subform.










  #7  
Old February 26th, 2010, 05:17 AM posted to microsoft.public.access.tablesdbdesign
Dennis
external usenet poster
 
Posts: 1,222
Default Church Database

Fred,

You correct about Allen's approach. I did not mean for Lyndsey to follow
that, I meant it more as background information. However, I guess I should
have included that little bit of informaiton. Whoops. Sorry, my mistake!

The reason I suggested keeping the head of house status field / flag was two
fold.

1. This will enable the churc to easily send a mailing to just "the
family" via the head of house hold. The mailing label report would select
every member with a head of household status.

2. I suggested that the sub-form puting the head of household "people id"
on a data field on the family table. I was thinking that way the Family
Table could link directly to the People table using the head of household's
"people id" as a foreign key.

This would enable Lyndsey to create a name search combo box on the main form
where she can enter the head of household's name, have it display the family
names in the drop down combo box, and let her users select the family from
the list.


Lyndsey

Please do try to implement Allen's full approach. I agree with Fred., the
two tier is bad enough.

Also, I have some code that allows to to specify how many lables to skip on
a page before you start printing the actual labels. That way you don't have
to want labels. I forgot where I got it from, but I will be glad to pass it
on to you.

If you need more help, please post your questions. Most of us still believe
in helping each other for free.

If you have problems developing this form, please let me know. I've been
thinking about it for quite a while and I would not be opposed to developing
a form form my own uses and then giving you a copy.


Dennis

  #8  
Old February 26th, 2010, 03:49 PM posted to microsoft.public.access.tablesdbdesign
Dennis
external usenet poster
 
Posts: 1,222
Default Church Database

Lyndsey,

I'm sorry, my brain was working faster than my fingers.

While I typed "Please do try to implement Allen's full approach.", I was
thinking "Please do NOT try to implement Allen's full approach."

As Fred stated, the two tier approach should work great for what you are
doing.


Good luck.


Dennis

  #9  
Old February 27th, 2010, 10:07 PM posted to microsoft.public.access.tablesdbdesign
Kathy R.[_3_]
external usenet poster
 
Posts: 25
Default Church Database

Lyndsey,

I'm also working on a church database - actually re-creating one that I
made more than a decade ago. I've learned a lot since then and
discovered several things I did wrong that needed correcting. I am by
no means an expert, but with the help of these fine folks here (barring
Steve, who seems to keep asking for money even though these are FREE
forums and advertising isn't allowed), I keep getting better.

You will definitely want at least two tables, one for Family information
and one for Individual Information.

tblFamily
FamID (a unique autonumber)
FamLastName (the family's last name - beware, not all people in the
family have the same last name, but if you're addressing Mr. and Mrs.
it's handy to have here)
Address (street address/PO Box)
City
State
ZipCode
HomePhone

tblIndividual
IndID (a unique autonumber)
InFamID (a foreign key to link to the tblFamily)
FirstName
MiddleName
LastName (for those folks that have blended families or hyphenated last
names)
Suffix
Gender
ContactStatus (I use "Primary Contact, Secondary Contact, Child, Other
Adult" - this way you can mail to individuals or families)
DateOfBirth

A couple of other things to consider:

Phone numbers - There's two types of phone numbers - a home phone,
linked to the family/address and other phones linked to individuals. I
finally decided to have a separate table for phone numbers, linked to
the tblIndividual. People have cell phones, work phones, cell phones
for work...

Email addresses - this could go into the tblIndividual, but I am also
finding that I'm getting more and more alternate email addresses. For
that reason I'm also breaking the emails out into their own separate
table linked to the Individual's table.

Regular addresses - I've actually put the addresses in their own
separate table too. We have several people that head south for the
winter. Instead of having to change their address every six months, I
can now just check which address is active. This also covers kids that
head off to college. They have both a home and a college address.

Committees and Groups (everything from Church Council to 1st Grade
Sunday School Class to Volunteer Gardeners) - DON'T do as I did the
first time around and have a yes/no field in the tblIndividual for each
committee/group! It's a nightmare to keep up to date that way and is
just plain poor design. Instead you'll need two more tables so that you
can handle One-to-Many relationships going both ways (One member belongs
to many groups, One group has many members.

tblGroup
GroupID
GroupName
GroupDesc

tblGroupMembers (I call this a join table, but there's probably a proper
name for this kind of table)
GroupMemID (primary key autonumber)
GMGroupID (foreign key linked to tblGroup)
GMIndID (foreign key linked to tblIndividual)
GroupPos (president, chairperson, member, etc.)
Term

Phew! It looks complicated here, but once you have it set up correctly,
entering information is quite easy. If you go with just the Family and
Individual tables, you'd could use a pretty simple Form/Subform. The
main form is where you'd enter the family's information (Last Name,
address, home phone), with a Subform, that is linked via the
Parent/Child property, where you enter information for each individual.

Having said all that, I am just an "upper level beginner." Hopefully,
if I've pointed you in the wrong direction here, the experts will step
in and correct me!

Good Luck, and remember, there's no dumb questions!!

Kathy R.

MissThing wrote:
Trying to put together a simple database for our church directory and
records. We need contact info as well as DOB and group involvement etc. Make
directories, labels, email groups and basic reports. Which I had no problems
with. What I am having issues with is the family relationship thing. We
often need to do mailings per household as well as individuals. What is the
best way to "group" my families. And how should they be entered? I thought
making a check box to designate a "head of household" and when entering
choose a family. Or have a seperate form for "families" THEN enter
individuals designateting them to that family. I don't want to have a whole
lot of tables and things. I really want this as simple as possible with as
little things that could get messed up down the road.

also this will hold our deceased records. Should we have a whole seperate
DB for that? or just have it together. This is not the main issue though and
can handle that at some other time. Right now I just have deceased as a
option under status.

Thank you so much for your time!

Lyndsey

I should mention I'v just altered the sample contacts template.

  #10  
Old February 28th, 2010, 12:10 AM posted to microsoft.public.access.tablesdbdesign
Dennis
external usenet poster
 
Posts: 1,222
Default Church Database

Kathy,


I like what you did winter and summer address. Very nice. We have the same
issue here in Florida, except in reverse.


Dennis
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 03:04 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.