I’m struggling with a particular table; it seems to me that it currently violates the “Data should be single valued” rule of database design. Or does it…..?
Table1 has SYSTEM_ID, ModelA, ModelB, ModelC, ModelD and ModelC columns. The SYSTEM_ID column combined with one of the Model columns produces a PK (In other words, SYSTEM_ID’s are unique per Model). However, the same System can be present in one to many models. For example, SYSTEM_ID “54321ABC” could be present in both ModelA and ModelB products.
NOTE: Currently this distinction is achieved by placing an “X” in the Model fields for a given SYSTEM_ID.
To me, it seems that the Models should go in their own table. However, because each SYSTEM_ID can have several Models, I can’t figure out how to do it without creating a multi-value field (which I don’t want to do since this will eventually get moved to SQL Server).
Is the current table structure the best to avoid duplicate data? Or, does this need to be separated somehow?
Much thanks!
Alex
Table1 has SYSTEM_ID, ModelA, ModelB, ModelC, ModelD and ModelC columns. The SYSTEM_ID column combined with one of the Model columns produces a PK (In other words, SYSTEM_ID’s are unique per Model). However, the same System can be present in one to many models. For example, SYSTEM_ID “54321ABC” could be present in both ModelA and ModelB products.
NOTE: Currently this distinction is achieved by placing an “X” in the Model fields for a given SYSTEM_ID.
To me, it seems that the Models should go in their own table. However, because each SYSTEM_ID can have several Models, I can’t figure out how to do it without creating a multi-value field (which I don’t want to do since this will eventually get moved to SQL Server).
Is the current table structure the best to avoid duplicate data? Or, does this need to be separated somehow?
Much thanks!
Alex
