As long as we're beating the dead horse, might as well break out the shotgun:

I'm thinking along similar lines as you with the declaration of the primary key.  We obviously can't use strCode as a Primary Key or part of a primary key (nullable).  Ditto on the naming conventions - VB6 programmers would be the only people I could think of who would name their columns like this - because of an MS aberration of the so-called 'Hungarian notation'.

But anyway, if we declare the PK as (strDescription, strCategory), we're using the data itself as a PK.  Sort of defeats the purpose of a PK and any potential optimizations it might provide.

And I agree that there's no reason to store the state information multiple times; although with this type of design you can expect a programmer to add the same attributes into the table multiple times rather than try to hunt through the table for existing codes that might be applicable.  If you are listing States that have offices for your company - as opposed to a complete listing of all states - you will duplicate the data over and over using this method.