Você pode querer considerar um modelo de dados Tipo/Subtipo. Isso é muito parecido com classe/subclasses na programação orientada a objetos, mas muito mais difícil de implementar, e nenhum RDBMS (que eu conheça) os suporta nativamente. A ideia geral é:

• Você define um tipo (edifício), cria uma tabela para ele, dá a ele uma chave primária
• Você define dois ou mais subtipos (aqui, Hospital, Clínica, Escola, Universidade), cria tabelas para cada um deles, faz chaves primárias... mas as chaves primárias também são chaves estrangeiras que fazem referência à tabela Building
• Sua tabela com uma coluna "ObjectType" agora pode ser criada com uma chave estrangeira na tabela Construindo. Você teria que juntar algumas mesas para determinar que tipo de construção é, mas você teria que fazer isso de qualquer maneira. Isso ou armazenar dados redundantes.

Você notou o problema com este modelo, certo? O que impede um Edifício de ter entradas em duas ou mais tabelas de subtipo? Que bom que você perguntou:

1. Adicione uma coluna, talvez "BuildingType", a Building, digamos char(1) com valores permitidos de {H, C, S, U} indicando (duh) o tipo de edifício.
2. Crie uma restrição exclusiva em BuildingID + BuildingType
3. Tenha a coluna BulidingType nas subtabelas. Coloque uma restrição de verificação nela para que ela só possa ser definida para o valor (H para a tabela Hospitais, etc.) Em teoria, isso poderia ser uma coluna computada; na prática, isso não funcionará devido à seguinte etapa:
4. Crie a chave estrangeira para relacionar as tabelas usando as duas colunas

Voila:Dada uma linha BUILDING definida com o tipo H, uma entrada na tabela SCHOOL (com o tipo S) não pode ser definida para fazer referência a esse Building

Você deve se lembrar que eu disse que era difícil de implementar.

Na verdade, a grande questão é:vale a pena fazer isso? Se fizer sentido implementar os quatro (ou mais, conforme o tempo passa) tipos de construção como tipo/subtipo (vantagens adicionais de normalização:um local para endereço e outros atributos comuns a cada construção, com atributos específicos de construção armazenados nas subtabelas), pode valer a pena o esforço extra para construir e manter. Caso contrário, você está de volta à estaca zero:um modelo lógico que é difícil de implementar no RDBMS moderno médio.