- Local time
- Yesterday, 21:40
- Joined
- Feb 28, 2001
- Messages
- 30,214
The idea of "what's wrong with it" is as I stated. You have phases with so many dependencies that it almost can't be created.
Let's try this again. You have
tblSite - with a SiteID as PK, plus other geographic data.
tblPhase - linked to Site, depends on site.
tbl RCC - this CANNOT BE DIRECTLY LINKED TO ANYTHING in the Site or Phase tables because they don't depend on RCC. (Believe it or not... read on to see what I mean by this.)
You CAN make a junction table between phases and RCCs. As you stated, RCC can apply to more than one phase. The JUNCTION between Phase and RCC is a child of two tables - AND solves the problem that a single RCC might apply to many phases.
You would make one entry in the RCC/Phase table (containing an RCC ID and a phase ID as a minimum, other fields possible) for each phase that a given RCC covers. So that is how you implement that relationship. While I cannot be sure, I suspect that the other tables you showed earlier in your relationship diagram will be the same way.
The technical reason that your originally diagrammed relationship is at the very least unlikely is that it says - in order to have a phase, you must have every one of those other things - a site, an RCC, and the two other tables - all at once.
But that's not true. You start from a site and you lay out your phases whether you have an RCC or not. You just have to wait for the RCC to start work on that phase - but it can exist (on paper and in a legal ownership sense) without an RCC. Your relationship diagram says it could not.
Let's try this again. You have
tblSite - with a SiteID as PK, plus other geographic data.
tblPhase - linked to Site, depends on site.
tbl RCC - this CANNOT BE DIRECTLY LINKED TO ANYTHING in the Site or Phase tables because they don't depend on RCC. (Believe it or not... read on to see what I mean by this.)
You CAN make a junction table between phases and RCCs. As you stated, RCC can apply to more than one phase. The JUNCTION between Phase and RCC is a child of two tables - AND solves the problem that a single RCC might apply to many phases.
You would make one entry in the RCC/Phase table (containing an RCC ID and a phase ID as a minimum, other fields possible) for each phase that a given RCC covers. So that is how you implement that relationship. While I cannot be sure, I suspect that the other tables you showed earlier in your relationship diagram will be the same way.
The technical reason that your originally diagrammed relationship is at the very least unlikely is that it says - in order to have a phase, you must have every one of those other things - a site, an RCC, and the two other tables - all at once.
But that's not true. You start from a site and you lay out your phases whether you have an RCC or not. You just have to wait for the RCC to start work on that phase - but it can exist (on paper and in a legal ownership sense) without an RCC. Your relationship diagram says it could not.
The problem with this is that the RCC will only appear for one phase when a query is run even though it cover phase1 and phase2.
[\QUOTE]
This way, you have a separate pointer to the common RCC - but structurally you can now do a lookup from the pointers. Trying to directly point to the phase from the RCC, as you have noted, gets you nowhere because one RCC record can only really point to one phase. Your "start phase" and "end phase" values vanish now, to be replaced by a list of the applicable phases for that RCC.
Let me try another analogy to give you the mental picture of why your structure was so troublesome. You had four independent trees of different species with a single root system. So of course, Access the arborist didn't know WHAT kind of tree you really had. You were WAY beyond apples and oranges. You had a four-fruit ambrosia mix going on in that diagram.