We help along the referential integrity by setting foreign key values when you specify a relationship within the business objects, but we don't enforce referential integrity; that's the sole responsibility of the database.
As for using a dummy record, there are a couple of ways you could go about doing this. You could know the PK ahead of time, either because you manually assigned it (IDENTITY INSERT ON) and always use the same PK, or because you put a flag on the record and retrieve it when you start up the application. Either way you would have the PK in a shared variable or a constant somewhere that would allow you to assign the value within the SetDefaultValues() of a business object. So, records would start out bound to that dummy record unless the user chooses to assign them to a different building.
Like I said, though, you certainly don't have to use a dummy record, and if keeping track of the dummy record is a pain, then using 0 (which you would always know) would certainly work, too, but you would have to turn off the enforcing of your PK (cascading deletes/updates would still work, though because you have the relationship defined, turning off the enforcement only prevents the DB from throwing an exception when the relationship isn't followed).