Re: PK & FK problems in data consolidation

Thanks Michael for your input. I am still open for redesigning it, since I
just finished it recently, is it a big job?. The relationsip is all the same
I think except that instead of surrogate PK, now we want to make it the even
5 field PK ?(member,church,Regional, Union,Division) of member table and 5
field PK (address,church,Regional,Union,Division) of household address table.

My question is should we make also the 5 FK of this?. HouseholdAddress table
related to member table as one to many. Should we have 5 FK also in
membertable?.
In order to have a memership report by church, by regional, by Union, by
Division), I have related the following tables with One to many relationship:
1. Church to member
2. Regional to Church
3. Union to REgional
4. Division to Union

Should we have a 5 field FK in member,church, regional, division tables?.
Does affiliation table will take care the combination of the FK too?. Address
and member ID since it will be increasing as we enter the data, column should
also be primary key too?.

Thanks for your kind help.
--
H. Frank Situmorang


"Michael Gramelspacher" wrote:

On Mon, 3 Nov 2008 06:32:00 -0800, Frank Situmorang <hfsitumo2001@xxxxxxxxx> wrote:

Yhanks Michael for your comprehensive explanation, I have those tables in my
database except the affiliation table what is that for.

I have sent you my database thru your email and explained my problems,
thanks for your helps

You have a complete functioning database program with multiple forms and reports. Now you want to
expand the usage of this database throughout the church hierarchy. The problem is that the database
uses an autonumber key unique to each church. You are looking for an easy fix which will allow you
to basically keep things about as they are. I do not see how you can avoid redesigning the
database.

I do not understand your table structure and cannot read the table names, because they are in a
foreign language. I see only two defined relationships in the relationship window, and they are
defined in the front end.

The Affiliation table brings ChurchID, RegionID, UnionID and DivisionID together. It defines the
allowable combinations of Church, Region, Union and Division. Member table is joined to the
Affiliation table. This is for data integrity so as to define valid combinations.

I really do not know where you can go with this. Maybe there are still other ideas out there.

.

Relevant Pages

  • Church Organizer Pro 1.7
    ... Church Organizer Pro is a flexible database management software with ... ready to use church membership management solutions. ... ready-to-use church member management solutions make it easy to set up ... Complete database template that gives you an easy way to ...
    (comp.software.shareware.announce)
  • Re: PK & FK problems in data consolidation
    ... They have to ask us we can call it affiliation number, ... us name of his Division, Union, and Regional and Church. ... Now my question is can we make the member PK of our Kebayoran SDA church ... database except the affiliation table what is that for. ...
    (microsoft.public.access.formscoding)
  • Re: Multi_field Primary Key to FK
    ... tblChurchname is church table ... level I have a primary key of address table linked to the member table ... each church will have a database and its data ... the Primary Key could duplicate. ...
    (microsoft.public.access.formscoding)
  • Re: 4 Fields PK linked to 1 field FK
    ... church and it works, we know the member of the family per household. ... RegionID INTEGER NOT NULL, ... DivisionID INTEGER NOT NULL); ...
    (microsoft.public.access.formscoding)
  • Re: Multi_field Primary Key to FK
    ... Thanks Tina for your quick response. ... Formely I have a one field PK in my church database. ... the PK is always for each member and their addresses. ...
    (microsoft.public.access.formscoding)
Loading