vendredi 11 décembre 2015

Database / table structure - similar entries vs. too much normalization?

I have designed this relational database that is keeping track of various assets and their owners over time. One of the most important piece of analysis I want to do is to track the value of those assets over time: expected original cost, actual original cost, actual cost, etc. So I have been putting data relative to a cost / value in a separate table called “Support_Value”. To complicates things some of the assets I’m tracking are in countries with foreign currencies so I’m collecting cost / value data in US Dollars but also in local currencies (“LC”), which ends up doubling the number of columns I have in this table. I also use this table as a way to keep track of the value of the asset owners themselves in a similar fashion. - The columns of this table are the following: enter image description here

My initial plan was to carve out separate tables to deal with (1) the various “qualities” of entries relative to cost and value (i.e. the “planned”, “upper” bound, “lower” bound”, “estimated” by analysts, and “actual” and another table to track) and (2) another one for currencies. But I realize this is likely to break as it doesn’t allow to have an initial “planned” cost that is then subsequently revised unless we make it explicit by creating new column for revised appendages but then there can be more than one revision.. So still not perfect.

What I’m now envisaging is to create a different value table that would have the following columns:

  • ID (PK representing individual instances of cost / value estimates)
  • Currency (FK to my currency table)
  • Asset (FK to my assets table) - i.e. what this cost or value is referring to
  • Date (FK to my date table) - i.e. to track revisions actually
  • Type (i.e. “cost" or “value")
  • Quality (i.e. “planned”, “upper”, “lower”, “estimated”, “actual”)
  • Valuation - i.e. the actual absolute amount in the currency designated in the second column

What do think of this approach? Is this an improvement?

Thanks for any suggestion you could have!

Aucun commentaire:

Enregistrer un commentaire