1) Сущность "Организация" представляет собой отдел, у которого id_parent_otd = NULL, т.е. незачем отделы и организации разносить по разным сущностям. В этом случае все сущности, которые ссылаются на организацию и на отдел одновременно (мейл, сайт и т.п.) избавляются от лишнего поля. И работников можно привязать как к подчиненным отделам, так и к организации. И список всех сотрудников получить одним иерархическим запросом.
2) "Сущность ДОЛЖНОСТЬ с полями (id_dol, id_org, id_dol, name)" - зачем дубликат "id_dol"?
3) "организация и ее отделы могут находиться на разных этажах здания" - это как вообще? :)
4) Сущность АДРЕС. Допустим, нужно получить список организаций, чьи головные офисы находятся на ул.Кржижановского. Если оператор при регистрации организации сделает ошибку в мудреной фамилии, как можно будет получить _полный_ искомый список?
5) У организаций есть еще реквизиты: номер счета в банке и т.п.
6) "у организации и отдела общие .. номера кабинетов, номера этажей". Номера кабинетов будут перечислены через запятую в строке "Адрес" (после улицы, дома и т.п.)?. А как узнать, в каком из этих кабинетов сидит мегаслесарь 6-го разряда группы ремонта отдела Великих Работ? Если это узнать нельзя, зачем вообще номера кабинетов?
7) Справочник организаций полезен для поиска по видам деятельности (например, нужно найти фирмы, которые устанавливают стеклопакеты), поэтому неплохо указать эти самые виды деятельности и ссылки на них у сущности "Организация" (точнее, у сущности "Отдел" с id_parent_otd = NULL). Виды деятельности можно сделать двухуровневыми - категории и виды внутри категорий (например, медицина -> [стоматология, женская консультация, ветклиника, знахари и шарлотаны]).

Объекты предметной области
1) Группа сущностей «Адрес». В общем виде минимальный адрес состоит из двух полей – тип адреса и, собственно, адрес (город Воркута, село Ершово, автономная_республика Крым). Адрес может ссылаться на другой адрес, глубина вложенности неограничена (например: улица Чапаева -> район Центральный -> город Верхнефуцынск). «Дом» или «Здание» есть тип адреса (например: дом 6 -> улица Чапаева -> …).
2) Исходя из п.1, имеем две сущности – ТИП_АДРЕСА (ADRESS_TYPE) - дом, улица, город и АДРЕС (ADRESS) - тип адреса с названием, необязательными географическими координатами и т.п.
3) ВИД ДЕЯТЕЛЬНОСТИ (ACTIVITY). Одни виды могут быть подвидами других, глубина вложенности видов неограничена.
4) ОРГАНИЗАЦИОННАЯ СТРУКТУРА (STRUCTURE). Это фирма, ее отдел, лаборатория внутри цеха и т.д. Организационные структуры состоят из аналогичных структур низшего уровня, которые также состоят из оргструктур и т.д. Глубина вложенности оргструктур неограничена. Каждая структура может заниматься разными видами деятельности.
5) ДОЛЖНОСТЬ (POSITION). Оргструктуры состоят из должностей. Каждой должности соответствует адрес, один или несколько контактов различных видов.
6) У каждой оргструктуры имеется официальное лицо (например, секретарь) – это должность с логическим признаком «Секретарь». Адрес и прочие контакты секретаря рассматриваются в качестве официальных контактов всей структуры (именно поэтому у самой сущности «оргструктура» нет соотв. полей). Это логично, т.к. структура может быть разделена по нескольким адресам (один лифтер по такому адресу, второй – по такому, а начальник лифтеров – по третьему; у всех, само собой, разные телефоны).
7) Исходя из п.п.5 и 6, для каждой должности в качестве адреса указываем дом (здание), который, в свою очередь, ссылается на улицу, она – на город и т.п. «Кабинет» («помещение») – отдельное свойство сущности, в состав адреса не входит. Оно может быть строковым, а может быть ссылкой на отдельную таблицу кабинетов. Поскольку в схеме топикстартера фигурируют этажи, то выделим сущность КАБИНЕТ (ROOM), у которой есть свойство «этаж». Таким образом, имеем цепочку ОРГСТРУКТУРА – ДОЛЖНОСТЬ – АДРЕС (напр., город – улица – здание) – КАБИНЕТ (номер и этаж).
8) Теперь с учетом п.7 возвращаемся к п.5. Каждой должности соответствует не адрес, а кабинет, а уже кабинет привязан к адресу.
9) Контакты. Имеем две сущности – ВИД_КОНТАКТА (CONTACT_TYPE) - телефон, емейл, сайт, скайп, .. и КОНТАКТ (CONTACT) - вид контакта и его значение – номер телефона и т.п. Каждой должности может соответствовать 0 и более контактов разных видов.



Например, один из аспектов формирования справочника организаций с учетом приведенной выше структуры:
ООО «Нанотехнологии Дрыщанска» - ул.Маркса, 18
- директор - каб.204, тел. 123-456
- секретарь – каб.205, тел. 123-400
- сантехник высшей категории – ул.Абрамовича, 32, каб.104, тел. 454-239.
Здесь секретарь – это должность с признаком «Секретарь» = TRUE, поэтому адрес секретаря - «ул.Маркса, 18» - официальный адрес организации. При выводе на экран должностей этой организации те из них, чьи кабинеты ссылаются на адрес, совпадающий с официальным, выводятся без указания адреса (чтобы не захламлять страницу справочника). А вот кабинет сантехника ссылается на другой адрес и потому последний выводится полностью.

Не за что, рад, раз она оказалась полезной.

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

Как вариант, можно отказаться от сущности КАБИНЕТ, привязав АДРЕС напрямую к ДОЛЖНОСТИ. При этом пропадет атрибут "Этаж", который, в общем-то, и не особо важен.

Ну да, каждая запись АДРЕС создается отдельно. Например, пишем хранимую процедуру, у которой на входе:
- ID типа адреса
- ID родительского адреса
- наименование нашего адреса