Member - Member Account Physical Representation
2 posters
Page 1 of 1
Member - Member Account Physical Representation
Hi
I have the entity Person who can be of type Member and Beneficiary at the same time. A person is a Member if the person has one or more current Accounts. The time span of a Member is the first join date of the Accounts associated with the Member until the last exit date of the Accounts associated with the Member (all accounts have exited)
In my physical model I have the Person dimension and an Account dimension. Do i need a bridge table (Member) to link the the dimensions, this bridge table has start date, exit date and status (current, exited) attributes ?
Regards
Tim
I have the entity Person who can be of type Member and Beneficiary at the same time. A person is a Member if the person has one or more current Accounts. The time span of a Member is the first join date of the Accounts associated with the Member until the last exit date of the Accounts associated with the Member (all accounts have exited)
In my physical model I have the Person dimension and an Account dimension. Do i need a bridge table (Member) to link the the dimensions, this bridge table has start date, exit date and status (current, exited) attributes ?
Regards
Tim
tim_goodsell- Posts : 49
Join date : 2010-09-21
Re: Member - Member Account Physical Representation
3 Possible ways to implement this -
1. De-normalize Person related attributes in to Account dimension. This will help you get all the required information for Account and Person holding the account from single dimension only " Improved performance". ( Be careful of Join account scenario).
2. No need to create Bridge table as Person and Account dimensions can be connected through Fact table, because any transaction happening for an account will always have Account and Concern Person attached to it. Hence you can get all the required information.
3. You can create Bridge table between Account and Person only if you want static list report detailing Account and Persons, this will give you master details for Accounts and Persons. My advice is if you are going by this approach try to make best use of this Bridge table by keeping all required information into it.
1. De-normalize Person related attributes in to Account dimension. This will help you get all the required information for Account and Person holding the account from single dimension only " Improved performance". ( Be careful of Join account scenario).
2. No need to create Bridge table as Person and Account dimensions can be connected through Fact table, because any transaction happening for an account will always have Account and Concern Person attached to it. Hence you can get all the required information.
3. You can create Bridge table between Account and Person only if you want static list report detailing Account and Persons, this will give you master details for Accounts and Persons. My advice is if you are going by this approach try to make best use of this Bridge table by keeping all required information into it.
Abhiraizada- Posts : 20
Join date : 2011-05-24
Similar topics
» How to represent boolean flag representation in FACT?
» determine grain by the physical realities of the data's source
» Calculated Member Question
» Tool to capture physical metadata, logical business model and relationship between the two?
» Member eligibility dimension / fact
» determine grain by the physical realities of the data's source
» Calculated Member Question
» Tool to capture physical metadata, logical business model and relationship between the two?
» Member eligibility dimension / fact
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum