Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

For my purposes I'm trying to apply this to Microsoft SQL, but would like to know if there are restrictions for other DBMS regarding this.

I don't know how to represent UML as ascii characters so if someone has a tool suggestion to do so please add in comments.

Example of the scenario below. Note that I'm using composite keys.

building
------------------------------------
+ buildingFullName:String(30) <<PK>>
+ buildingId:Int <<SK>> <<PK>>

buildingRoom
------------------------------------
+ buildingId:Int <<PK>>  <<FK>>
+ roomNumber:String(10) <<PK>>
+ roomId:Int <<PK>> <<SK>>

buildingRoomAsset
-------------------------------------
+ roomId:Int <<PK>> <<FK>>
+ roomAsset:String(9) <<PK>> <<SK>>
share|improve this question

1 Answer 1

If you are using composite primary keys, your foreign key references would also need to be composite keys. If the primary key of building is (buildingId, buildingFullName) then buildingRoom would need to have both a buildingId and a buildingFullName that would be the foreign key to building. Similarly, if (buildingId, buildingRoom, roomId) is the primary key of buildingRoom, you would need all three of those columns in buildingRoomAsset in order to create the foreign key. Defining the foreign keys this way doesn't make sense.

If you are adding a surrogate key to the table, you would almost always want to define that column and that column alone as the primary key of the table. You can add additional unique constraints to ensure that things like the buildingFullName are unique within the table. Adding the buildingFullName to the primary key not only forces the buildingFullName to be pulled through to all the child tables, making it much more difficult to update the data, it means that you can have many buildings with the same name which seems unlikely to be what you're after.

Additionally, I would strongly suspect that you want an asset table that stores information about assets and then a roomAsset table that maps a roomId to one or more assetId values. That will make life much easier when an asset gets moved from one room to another among other use cases.

If it were me

building
------------------
+ buildingId <<SK>> <<PK>>
+ buildingFullName 

room
------------------
+ roomId <<SK>> <<PK>>
+ buildingId <<FK>>
+ roomNumber

asset
------------------
+ assetId <<SK>> <<PK>>
+ assetName

roomAsset
------------------
+ roomAssetId <<SK>> <<PK>>
+ roomId <<FK>>
+ assetId <<FK>>
share|improve this answer
    
I see the point about difficulty to update information with my initial design. I had forgotten about the Unique constraint which is probably then what I will end up using to maintain normalization. –  Sn3akyP3t3 Oct 31 '12 at 22:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.