Need help interpreting table schema (i.e. strvalue, bvalue, dvalue, lvalue)
I recently took over a database and I'm not sure how to interpret the design. Please see the picture below for a glimpse at two tables.
These tables are linked to other tables such as SiteOffice, Department, HardwareManuf, HardwareCategory, HardwareItem
I could think of easier ways to create tables that would make the design easier to follow and update. I'm wondering what it is I'm missing. For example, I'm wondering why the 'strvalue' field is used to hold more than just the service tag of a workstation. It also can be used to hold an asset 'group' number (i.e. workstation, keyboard, monitor) ... and it can be used to hold an asset barcode. Any of these three could be referenced by the 'strvalue' field if the following statement were used:
SELECT F.uid As Group_ID, AF.StrValue, F.FieldType, F.Label
FROM AssetFields AF INNER JOIN HWFields F ON AF.FieldUID = F.UID
WHERE AF.AssetUID = 'XYZ123'
AND F.Label = 'Group'
The above query could also end with either of these two:
1) AND F.Label = 'Barcode'
2) AND F.Label = 'Servicetag'
Thus, since the 'strvalue' field accepts nulls as seen in the diagram below, isn't it safe to assume the only catch or filter on unique entry would be the user application that accepts new assets?
Again, what am I missing? Thanks!
table-design.JPG
These tables are linked to other tables such as SiteOffice, Department, HardwareManuf, HardwareCategory, HardwareItem
I could think of easier ways to create tables that would make the design easier to follow and update. I'm wondering what it is I'm missing. For example, I'm wondering why the 'strvalue' field is used to hold more than just the service tag of a workstation. It also can be used to hold an asset 'group' number (i.e. workstation, keyboard, monitor) ... and it can be used to hold an asset barcode. Any of these three could be referenced by the 'strvalue' field if the following statement were used:
SELECT F.uid As Group_ID, AF.StrValue, F.FieldType, F.Label
FROM AssetFields AF INNER JOIN HWFields F ON AF.FieldUID = F.UID
WHERE AF.AssetUID = 'XYZ123'
AND F.Label = 'Group'
The above query could also end with either of these two:
1) AND F.Label = 'Barcode'
2) AND F.Label = 'Servicetag'
Thus, since the 'strvalue' field accepts nulls as seen in the diagram below, isn't it safe to assume the only catch or filter on unique entry would be the user application that accepts new assets?
Again, what am I missing? Thanks!
table-design.JPG
ASKER
Ok. But as far as a unique entry for such things as a workstation service tag, do you agree there is no way there could be protection against duplicate entries?
I have 10 duplicates so I guess I could say case closed - but again, in theory, is there any way duplicates would be even be difficult to input?
Thanks
I have 10 duplicates so I guess I could say case closed - but again, in theory, is there any way duplicates would be even be difficult to input?
Thanks
ASKER
Here is the FieldValues table you mentioned:
table-design2.JPG
table-design2.JPG
ASKER
Putting the question a different way, would you agree that just because the 'uid' for FieldValues is a unique identifier, this uid is not associated to the 'strvalue' for constraint purposes, right?
Well, this design does mean that foreign keys can't really be used in this area.
You might try some unique constraints, though. Would it be accurate to say that, in the AssetFields table, AssetUID, FieldUID, and strValue should form a unique combination? Also that none of the 3 fields should ever be NULL?
It looks that way from here ...
If so, I would make those 3 fields NOT NULL, then create a Unique constraint on them. After deleting the duplicate data, that is. A delete on a self-join should do that ... can write it if you need.
You might try some unique constraints, though. Would it be accurate to say that, in the AssetFields table, AssetUID, FieldUID, and strValue should form a unique combination? Also that none of the 3 fields should ever be NULL?
It looks that way from here ...
If so, I would make those 3 fields NOT NULL, then create a Unique constraint on them. After deleting the duplicate data, that is. A delete on a self-join should do that ... can write it if you need.
ASKER
>> A delete on a self-join should do that ... can write it if you need.
Sure, that would be great. Thanks!
Sure, that would be great. Thanks!
ASKER
Here are the results for a query that demonstrates the nulls already entered:
strValue-results2.JPG
strValue-results2.JPG
ASKER
>> Would it be accurate to say that, in the AssetFields table, AssetUID, FieldUID, and strValue should form a unique combination?
Could you pose any argument as to why they might not? I'm trying to envision the design but sometimes it's hard to see what was intended. I really have nobody to advise me on this because the previous developer is gone. I do know the types of assets which are tracked - basically soup to nuts (computers to tables & microwaves).
Given this information, do you see any reason why these columns would have allowed nulls on purpose?
Thanks
Could you pose any argument as to why they might not? I'm trying to envision the design but sometimes it's hard to see what was intended. I really have nobody to advise me on this because the previous developer is gone. I do know the types of assets which are tracked - basically soup to nuts (computers to tables & microwaves).
Given this information, do you see any reason why these columns would have allowed nulls on purpose?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>> For those NULL strValue's ... Are the AssetField records completely missing? Or do the AssetField records exist with NULL's in them?
I interpret those results as saying there are:
43 records all null except for the information given
1 records all null except for the information given
18 records all null except for the information given
106 records all null except for the information given
In other words, I think the application that is responsible for importing assets to the database was executing transactions with null values where seen. Why the application didn't have any values, I'll never know.
Is there some associated table that pops out in your mind that I should be looking in? The associated tables to me would be CatHWItem & CATHWType (category hardware), but the data they contain is also seen in the screen shot - right?
Thanks!
I interpret those results as saying there are:
43 records all null except for the information given
1 records all null except for the information given
18 records all null except for the information given
106 records all null except for the information given
In other words, I think the application that is responsible for importing assets to the database was executing transactions with null values where seen. Why the application didn't have any values, I'll never know.
Is there some associated table that pops out in your mind that I should be looking in? The associated tables to me would be CatHWItem & CATHWType (category hardware), but the data they contain is also seen in the screen shot - right?
Thanks!
ASKER
Thanks again for the help. The thoughts you discussed were certainly relevant!
Evidently, the field can have different types ... and the strValue is the key to determining which asset type it is.
It's not a very nice design, but I must admit to having done something similar before. I had an Address table that had an ObjectID and an ObjectType. The ObjectType was the key to tell whether the address was for a Customer, a Vendor, etc.
Without a more thorough look at the data, I can't say for sure, but that appears to be what this DB's designer is doing.