Adventure Works Explanation
I am not aware of any official design documentation for AdventureWorks, but I use to be a trainer and used AdventureWorks databases extensively for demos and labs, so I am pretty familiar with it.
The BusinessEntity table is a classic case of a SuperType/SubType design, which reduces data redundancy, because customers could also become vendors, employees could become customers, and every other combination. Also, it means that you are not storing details related to all entities repeatedly, in separate tables, minimising effort in the event of code changes.
The CountryRegionCode I am not positive about, but I would suspect one of three reasons:
- There are not enough distinct combinations to warrant an additional table at the expense of reporting performance (This could be validated with some simple COUNT(*) GROUP BY statements)
- They wanted it in the same table so that in future they had the flexibility to model a hierarchy structure with hierarchyID (This is the least likeley option)
- It was a normalisation error! (My money is on this option!)
This image helped me, even though it's technically for 2008.