Instead of using the key as the keycolum you could use the name of the attribute e.g.
key_size name_size
1 big
2 big
3 small
4 medium
if your keycolumn is key_size you will get four values if the keycolumn is name_size you will only get three where keys 1 and 2 are pointed to by the name_size big.
Hope that helps
Matt
The composite keys only really need to exist in the DSV to join the tables together, do they not Each individual attribute may not need composite keys. Think I must have missed something here, any chance of a more detailed example, perhaps two of the tables.
Cheers
Matt
Hi,
Ok i think i understand, it should look ok in the hierarchy yes. But if you browse the campaign attribute, it looks like there are duplicates, this is as expected. Two solutions, remove the composite key and do not make an attribute relationship between the attributes - thus giving you a little yellow triangle warning in the hierarchy.
OR, rename campaign to campaign2, create another attribute Campaign and don't use a composite key on that one, just the key campaign. If you want to browse the campaign list, just use campaign attribute but if you want to use the hierarchy use campaign2. In effect creating four attributes:
-Campaign
-Campaign2
-Account
-Dept
A hierarchy
-Dept
--Account
---Campaign2 (change its name to Campaign to reduce confusing the users)
And perhaps in the perspectives hide the individual attribute campaign2 so no one ever see it. Bit of a work around, but removes the duplicates.
Not to sure if there is another way of doing it. Maybe someone else has a better idea.
Hope that helps
Matt