规范化表6

Question

I'm putting together a database that I need to normalize and I've run into an issue that I don't really know how to handle.

I've put together a simplified example of my problem to illustrate it:

Item ID___Mass___Procurement__Currency__________Amount
0__________2kg___inherited____null________________null
1_________13kg___bought_______US dollars_________47.20  
2__________5kg___bought_______British Pounds______3.10
3_________11kg___inherited____null________________null   
4__________9kg___bought_______US dollars__________1.32

(My apologies for the awkward table; new users aren't allowed to paste images)

In the table above I have a property (Amount) which is functionally dependent on the Item ID (I think), but which does not exist for every Item ID (since inherited items have no monetary cost). I'm relatively new to databases, but I can't find a similar issue to this addressed in any beginner tutorials or literature. Any help would be appreciated.

Answer 1

I would just create two new tables ItemProcurement and Currencies .

If I'm not wrong, as per the data presented, the amount is part of the procurement of the item itself (when the item has not been inherited), for that reason I would group the Amount and CurrencyID fields in the new entity ItemProcurement .

As you can see, an inherited item wouldn't have an entry in the ItemProcurement table.

Concerning the main Item table, if you expect just two different values for the kind of procurement, then I would use a char(1) column (varying from B => bougth, I => inherited).

I would looks like this:

The data would then look like this:

TABLE Items
+-------+-------+--------------------+
|    ID |  Mass |  ProcurementMethod |
|-------+-------+--------------------+
|     0 |     2 |                  I | 
+-------+-------+--------------------+
|     1 |    13 |                  B | 
+-------+-------+--------------------+
|     2 |     5 |                  B | 
+-------+-------+--------------------+

TABLE ItemProcurement
+--------+-------------+------------+
| ItemID |  CurrencyID |     Amount |
|--------+-------------+------------+
|     1  |         840 |      47.20 | 
+--------+-------------+------------+
|     2  |         826 |       3.10 | 
+--------+-------------+------------+

TABLE Currencies
+------------+---------+-----------------+
| CurrencyID | ISOCode |     Description |
|------------+---------+-----------------+
|        840 |     USD |      US dollars | 
+------------+---------+-----------------+
|        826 |     GBP |  British Pounds | 
+------------+---------+-----------------+

Answer 2

Here is my off-the-cuff suggestion:

UPDATE: Mass would be a Float/Decimal/Double depending upon your Db, Cost would be whatever the optimal type is for handling money (in SQL Server 2008, it is "Money" but these things vary).

ANOTHER UPDATE: The cost of an inherited item should be zero, not null (and in fact, there sometime IS an indirect cost, in the form of taxes, but I digress . . .). Therefore, your Item Table should require a value for cost, even if that cost is zero. It should not be null.

Let me know if you have questions . . .

Answer 3

Not only Amount , everything is dependent on ItemID , as this seems to be a candidate key.

The dependence you have is that Currency and Amount are NULL (I guess this means Unknown/Invalid) when the Procurement is 'inherited' (or 0 cost as pointed by @XIVsolutions and as you mention "inherited items have no monetary cost" )

In other words, iems are divided into two types (of procurements) and items of one of the two types do not have all attributes.

This can be solved with a supertype/subtype split. You have a supertype table ( Item ) and two subtype tables ( ItemBought and ItemInherited ), where each one of them has a 1::0..1 relationship with the supertype table. The attributes common to all items will be in the supertype table and every other attribute in the respecting subtype table:

Item
----------------------------
ItemID    Mass   Procurement
0          2kg   inherited
1         13kg   bought
2          5kg   bought
3         11kg   inherited 
4          9kg   bought

ItemBought
---------------------------------
ItemID    Currency         Amount
1         US dollars       47.20  
2         British Pounds    3.10 
4         US dollars        1.32

ItemInherited
-------------
ItemID
0       
3    

If there is no attribute that only inherited items have, you even skip the ItemInherited table altogether.

For other questions relating to this pattern, look up the tag: Class-Table-Inheritance. While you're at it, look up Shared-Primary-Key as well. For a more concpetual treatment, google on "ER Specialization".

Answer 4

Why do you need to normalise it?

I can see some data integrity challenges, but no obvious structural problems.

The implicit dependency between "procurement" and the presence or not of the value/currency is tricky, but has nothing to do with the keys and so is not a big deal, practically.

If we are to be purists (eg this is for homework purposes), then we are dealing with two types of item, inherited items and bought items. Since they are not the same type of thing, they should be modelled as two separate entities ie InheritedItem and BoughtItem, with only the columns they need.

In order to get a combined view of all items (eg to get a total weight), you would use a view, or a UNION sql query.

If we are looking to object model in the database, then we can factor out the common supertype (Item), and model the subtypes (InheritedItem, BoughtItem) with foreign-keys to the supertype table (ypercube explanation below is very good), but this is very complicated and less future-proof than only modelling the subtypes.

This last point is the subject of much argument, but practically, in my experience, modelling concrete supertypes in the database leads to more pain later than leaving them abstract. Okay, that's probably waaay beyond what you wanted :).