Jump to content

Relationships - Need to confirm something


This topic is 4177 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi. I'm back on my Food Pantry project after taking a long break. I really need to complete this project. I unfortunately tend to get frustrated easily.

I'm trying to simply understand why I can't make this thing work and I think it's because I don't have my relationships properly identified and defined. Can someone please look over this scenario and tell me if I'm even on the right track.

Table structure (simplified)

Members - individuals with names, DOBs etc.

Households - many individuals from one person to several persons including children, live-ins, etc.

(Pantry) Sessions - daily freq, many households

Pantry Sessions: Individuals come visit, take out food. Sessions are opened daily, once per day. In my thinking, I see these inidiv visitors as being representative of Households because each household gets an allocation based on Household size (number of Members). So it's actually the "Household" that is visiting and drawing out food.

So here's what I see as far as relationships in FM is concerned:

1. Members <many-to-one> Households (pretty clear on that one)

2. Households <many-to-one> Sessions (fairly clear here, but...)

3. Sessions <many-to-one> Households (here's where I think I'm off)

Question A: Can relationships be "two-way" such as I have in 2. and 3. above? In that case, in FM I think I need two discreet sets of TOs in my diagram. Right? But, I'm not sure they can exist this way and work properly.

Question B: Is what 2. and 3. show really a many-to-many relationship? If so, I need to construct a join table I guess perhaps called "Transactions". Correct?

I believe I need to nail this concept down and comprehend it correctly before trying to waste more time building anything further such as layouts, scripts and so forth. As I've read: Gotta get the basics down first.

Am I OK or do I need to rethink this?

Thanks.

Hoib

Link to comment
Share on other sites

In general, relationships are bidirectional, so if you have defined a Parent -< Child relationship, you have defined both "one parent has many children" and "each child belongs to one parent" at the same time. However, some relationships will work only in one direction - for example when the matchfield on one side is a global field.

Pantry Sessions: Individuals come visit, take out food. Sessions are opened daily, once per day. In my thinking, I see these inidiv visitors as being representative of Households because each household gets an allocation based on Household size (number of Members).

1. Can members of a household take out food in "installments", i.e. more than once a day?

2. Is it important to record which member of a household made the visit?

Link to comment
Share on other sites

Thanks for comoing aboard. Members of a household could take out food in "installments" but they rarely if ever do. I can't think of an instance where this has happened historically. Usually it's in and out. However, say we had a bad flood or other emergency, after the person had visited. In that case, they could hit us twice. But again, that's extremely rare and very circumstantial. So, I'd say it's once per day 99.99% of the time. In reality, Households get to visit once per month. Unless financial circumstances warrant coming more often, like once per week (for a short duration).

It is important to record the person visiting. That's because that person might have other issues to discuss and take care of besides just drawing out food. I simplified my scenario down considerably - only to the point where I'd stripped everything back to the essentials - so I could get these essentials worked out.

I've tried to construct the join many times and it's failed, mostly because I'm still a novice. That's why I am back at square one with this project because I am thinking I have not properly defined what is many-to-one, and one-to-many.

I've avoided any further layout construction but let's say, the Pantry_Session layout is very simple and is going to have the name of person, how many in household, a few other incidental qualifiers, what position they are in queue.... that's if I can get something to work.

As I said, I'm just trying to get this basic thing to work. I believe the rest is going to be relatively easy. This is the core however, and at the top of the chain so to speak... Everything depends on this working properly.

Any further comment as I try to sort this out?

Hoib

Link to comment
Share on other sites

I am probably missing something, but it seems rather simple to me:

Households -< Members -< Visits

or, possibly:

Households -< Members -< Visits >- Sessions

The reason I hesitate between these two is that the role of a "session" is not quite clear. If all that describes a session is the date, then it's redundant.

Link to comment
Share on other sites

Oh, it's simple all right! I just can't get it to work the way we need it to...! I'm on FM 11 Pro Advanced thanks in large part to a generous donation by a parishioner.

A session has a date for sure. But it "pulls" data from other tables to assemble and display a record of the activity. The person's name comes from Members. The # in H/H comes from Households as does a USDA indicator, the weekly/monthly indicator plus it records the number of grocery bags taken, input by the session moderator. When the Member shows up, a drop down is used to find him. And then, I need to see the Household (in a portal) at the bottom of the display. I use the Member to "find" the Household. I then use the Household to build the service description. At the end of this, I need to do a "punishing" series of daily/monthly/quarterly numbers and reports breaking everything down by age, by zip, etc. That's why I think Sessions is key. It contains all the relevant details.

I thought I could build a layout for Sessions and use it for the moderator to run the food pantry session. I did but it fails. That's why I've gone back to inspect the whole basis.

I've shown a snapshot of the relevant parts of my Relationship diagram. Does this work in terms of what we've discussed so far?

post-92004-0-44709400-1350727133_thumb.j

Link to comment
Share on other sites

A session has a date for sure. But it "pulls" data from other tables to assemble and display a record of the activity.

A session (one) cannot pull data from other tables (many). In order to "display a record of the activity" you need to produce a report from the most atomic table - and that would be Visits.

A record in Visits contains all the relevant details - or, more accurately, has access to all the relevant details in all the other tables: a visit holds the MemberID, therefore it can "see" all the details of the member as they appear in the related record in Members. This record in turn is related to the parent Household, so the visits "sees" that as well.

Link to comment
Share on other sites

This topic is 4177 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.