Forum Discussion
Promotion Database
Hi George_Hepworth. Here are the summarized relationships.
1 Trade Activity = 1 Division (Essentially, under a division, there are several trade activities)
1 Trade Activity = Many Channels
1 Trade Activity = Many Areas
1 Trade Activity = Many Volume Allocations
What are your suggestions on this?
Thanks for the details. When each trade activity is undertaken on behalf of a single division, but each division can engage in multiple trade activities, that is a one-to-many relationship: one division to many trade activities. Your current diagram shows that properly, but, as previously noted, you should enforce Referential Integrity.
The other three appear to be many-to-many relationships. One trade activity can be conducted through many channels. One channel can be used in many trade activities, and so on for the other two.
The way we handle this is a junction table. It has at a minimum two fields. One is the TradeActivityID and the other is the ChannelID. In this junction, perhaps called TradeActivityChannel, the TradeActivityID is a foreign key to the TradeActivityID primary key in the TradeActivity table, and the ChannelID is a foreign key to the ChannelID primary key in the Channel table. In the TradeActivityChannel, these two fields together make up the primary key for that table. We usually refer to these as a Composite Primary Key. Sometimes additional fields are included, such as a DateEffective or DateEnded field if there is a time limit involved.
The same thing applies to the other two tables with many-to-many relationships.
The interface for these relationships will be a main form with subforms. Rather than try to explain it, I'll offer an example.