August 24, 2004 at 10:29 am
I'm having a dilema in identifying a proper modeling strategy for investment accounts. A model that I'm proposing seems like the right solution, yet it seems to violate normal forms (parts of a combined PK can be derived from a non key element). Can anyone provide some thoughts? See description of problem below.
An account has a taxtype. Taxtypes are:
+-----------------------------------------------+
|Code Description |
|------ ----------------------------------------|
|0 CMAIP |
|1 CMARSP |
|2 CMARIF |
|3 Self Dir. RRSP - Other |
|4 DO NOT USE; Self Dir. RRSP - MDM |
|5 Self Dir. RRIF - Other |
|7 Strategic Alliances |
|8 IPP |
|9 CMAP |
|A National Life RRIF |
|B SDIP |
|C SDRSP |
|D SDRIF |
+-----------------------------------------------+
Taxtype is used in various places to determine various tax implications on how an account should be treated.
An account has an account type.
+-----------------------------------------------+
|Code Description |
|------ ----------------------------------------|
|0 Individual |
|1 Spousal |
|2 Joint - single signature|
|3 Joint - multiple signature|
|4 MD Education Trust |
|5 Prof Corp |
|6 Locked-in |
|7 Association |
|8 Estate |
|9 EBP |
|A Family Trust - Non-recognized |
|B Family Trust - Other |
|E MD Registered Education Savings Plan |
|I Insurance |
+-----------------------------------------------+
AccountType is used in various places to determine rules for treating purchases / redemptions (allowing or disallowing, based on the accounttype).
An account has a statement description. This description is derived from the account's taxtype AND accounttype. This is the caveat: An account's taxtype is also deriveable from it's description, BUT an Account's AccountType IS NOT.
+------------------------------------------------------------+
|Tax Acct |
|Type Type vdesc |
|---- ---- --------------------------------------------------|
|0 0 CMA Investment Plan |
|0 1 CMA Investment Plan |
|0 2 Joint CMA Investment Plan |
|0 3 Joint CMA Investment Plan |
|0 4 MD Family Trust |
|0 5 Professional Corp. Investment Plan |
|0 7 Association CMA Investment Plan |
|0 8 Estate CMA Investment Plan |
|0 9 Employee Benefit Investment Plan |
|0 A MD Family Trust Investment Plan |
|0 B MD Family Trust Investment Plan |
|0 E MD Registered Education Savings Plan |
|0 i CMA Investment Plan |
|1 0 CMARSP |
|1 1 Spousal CMARSP |
|1 6 Locked-in CMARSP |
+------------------------------------------------------------+
The model I end up with is the one:
After a long winded question, here is my dilema: In the model shown, a portion of my combined primary key can be derived from a non-key attribute (In table AccountStatementDescriptionUsage, AccountTaxTypeCode can be derived from StatementDescriptionId). This seems to me like something that violates normal forms.
Is this a good approach or not?
August 25, 2004 at 1:50 am
Hi Brazem,
I want to have a look at your model and, hopefully, give you an answer to your question, but the image isn't visible. I noticed that the url for the image is file:///c:/temp/model1.jpg, which explains why I can't see it.
If you see a picture of Elvis, here's the way to add a picture:
If you're seeing two small white boxes with a red cross in it, there's something we're both missing . Maybe if there's to much time between inserting the picture and hitting the "Post Reply" button?
Cheers,
Henk
August 25, 2004 at 3:02 am
Without seeing the model, this is only an initial stab.
An account has a statement type. You don't need either tax type or account type since these can be derived from the statement type.
You would then create a view to pick up both the tax type and the account type.
Technically, an account doesn't have a tax type OR an account type, it DOES have a statement type. A statement DOES have a tax type and an account description. The statement type describes both how you prepare the statement and the handling of any tax returns (which impacts on the statement format).
Hope this helps.
August 25, 2004 at 7:02 am
Actually, jfmccaeb is correct. But, I would also add that you should have a structure something like this for you statement type table.
+------------------------------------------------------------------------+
|Statement Tax Acct |
|ID Type Type vdesc |
|--------- ---- ---- --------------------------------------------------|
|1 0 0 CMA Investment Plan |
|2 0 1 CMA Investment Plan |
|3 0 2 Joint CMA Investment Plan |
|4 0 3 Joint CMA Investment Plan |
|5 0 4 MD Family Trust |
|6 0 5 Professional Corp. Investment Plan |
|7 0 7 Association CMA Investment Plan |
|8 0 8 Estate CMA Investment Plan |
|9 0 9 Employee Benefit Investment Plan |
|10 0 A MD Family Trust Investment Plan |
|11 0 B MD Family Trust Investment Plan |
|12 0 E MD Registered Education Savings Plan |
|13 0 i CMA Investment Plan |
|14 1 0 CMARSP |
|15 1 1 Spousal CMARSP |
|16 1 6 Locked-in CMARSP |
+------------------------------------------------------------------------+
I do not recommend the use of a compound primary key for any reason. Use unique indexes to enforce the uniqueness of business rules that a compound key really is.
August 25, 2004 at 8:44 am
Ok, I've made the image available to everyone.
Also, I've added a small note to the initial problem for jfmccaeb and stewart: Although taxtype can be derived from a statement description, account type cannot.
So the alternative suggested by both does not meet all requirements.
Thoughts?
August 25, 2004 at 9:03 am
Same basic principle
Middle table will have fields:
And the Account table will simply have
August 25, 2004 at 10:12 am
I see says the blind man. To keep the above solution normalized, I would change it slightly as follows (since TaxType can be derieved from Statementdescription):
This is one of 2 or 3 theoretical solutions, which I always like to get to first. Remains to be seen how this will be implemented on our current system, where AccountType and TaxType are FK attributes of our Account table, and where we have limited support for SQL (our system is barely SQL92 compliant). But I'm cool from here!
Thanks for your thoughts
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply