Если структура одинаковая, то хранить однозначно надо все в одной таблице организаций. Делаете спрачоник типов организаций, а раз уж одна организация может быть нескольких типов, то делаете промежуточную таблицу с 2 полями - Код Организации и Код типа организации и соотвествующе связываете со справочниками. Получается многие-ко-многим, все будет работать.

Честно говоря не понял вопроса. Если вы о том - как узнать, что организация является воинской, то тут все элементарно - справочник типов организация можно сказать является статичным (я называю такие справочники системными) и пользователями изменяться не может. Вы спокойно можете вбить в него под жесткими кодами все существующие типы организаций и ссылатся на них в запросах. Но более удачным вариантом будет сделать вьювер, возвращающий Коды всех организаций, являющимися военными. Далее с таким вьювером будет легко манипулировать, что то типа того:


Таким же образом можно будет поделать вьювера на любые другие необходимые типы организаций и легко манипуляровать организациями.

В таблице "Организации-Категории" поле id не нужно - idОрганизация + idКатегория и будут являться primary key. Естественно тогда останется в связях воинской обязанности только одна конструкция:
Table ВоинскаяОбязанность
(...idВоенкомат reference Организация(id)...)

Почему это не удалим в таблице отношений ? Нормально удалим, так как 2 поля в этой таблице будут являться дочерними по отношению к таблицам организаций и типов организаций, а то, что они в связке образуют первичный ключ будет гарантировать нам уникальность информации и не позволит занести например дважды на одну организацию тип Военкомат. А удаления в родительских таблицах зависят только от логики и регулируются вами. Например связь Тип организации - Отношения будет правильно запрещать удаления записи в Типе организации, если на него ссылается хоть одна организация, чтобы не нарушить целостность данных организаций. А связь Организация-отношения фактически является подсвойством организации и при удалении организации все записи по этой организации в таблице отношений должны быть удалены. Это реализуется 3 путями и в основном зависит от возможностей SQL сервера - самый простой способ - указать каскадные удаления при создании связи между Организациями и Отношениями. Если каскадные операции не поддерживаются, то необходимо написать свой триггер на удаление записи в таблице Организаций, в котором нужно удалить все записи, имеющие код удаляемых организаций. Если тригерра тоже не поддерживаются, то перед удалением организации сначала придется вручную выполнять скрипт, аналогичный скрипту триггера, заключив скрипт удаления Отношений и Организаций в транзакцию, чтобы гарантировать целостность данных.

Вообще, чтобы не запутаться во всех этих связях, необходимо всегда четко разделять для себя связи, которых может быть 2 вида:
1. Свойства родительского обьекта - например каждая запись в Отношениях определяет свойство организации принадлежности к типу организаций
2. Ссылки на другой обьект - например каждая запись в Отношениях ссылается на определенный тип организации в таблице Тип организаций

Обычно свойства обьекта не должны ограничивать его удаление, т.е. если нам разрешено удалить организацию, то его свойства в таблицах Отношения тоже должны автоматически удалиться. Естественно бывают исключения - например когда свойства при определенных условиях уже не могут быть удалены, что может разруливаться опять же с помощью каскадных удалений и тригерров самой таблицы свойств (в нашем случае таблицы Отношений). Если удаление в подчиненной таблице по каким то причинам будет прервано, то удаление записи в таблице Организаций не состоится, и это будет правильно.

Ссылки же всегда должны хранится как связи без всяких каскадных удалений. Это будет гарантировать, что в справочниках можно будет удалять только ту информацию, на которую никто не ссылается.