Как правильно организовать связи... Конкретный пример.

Имеются следующие сущности:
Организация (id, ...)
Здание (id, )
Адрес (id, street_id, streetCheked, houseNum, houseCheked, office, officeCheked)
Здесь streetCheked, houseCheked, officeCheked - поля типа bool (= true, если соответствующие данные проверены)

Словесное описание:
- организация может занимать целое здание (в этом случае адрес конкретизируется до номера здания) либо располагаться в одном из офисов здания (в этом случае адрес конкретизируется до номера офиса)
- организация может иметь 3 адреса: фактический, юридический, почтовый
- адрес здания конкретизируется до номера здания
- каждый адрес организации (фактический, юридический, почтовый) территориально связан с одним из зданий
- каждое здание может иметь адрес, а может и не иметь (если адрес неизвестен либо ещё не введён в БД)
- каждый адрес каждой организации может быть задан, а может быть НЕ задан (если адрес неизвестен либо ещё не введён в БД)
- каждое поле адреса в отдельности может иметь разные cheked-статусы (например, streetCheked = false, houseCheked = true)
- в каждый момент времени организация может иметь некоторый адрес, но при этом соответствующее здание в БД может отсутствовать (например, в справочнике может присутствовать московская организация, тогда как здания в БД загружены только для Новосибирска)

Как организовать связь всех этих сущностей ?
Предлагаем варианты.

Добавил ещё пару условий. Модераторам просьма удалить предыдущий пост.

Имеются следующие сущности:
Организация (id, ...)
Здание (id, )
Адрес (id, street_id, streetCheked, streetNote, houseNum, houseCheked, houseNote, office, officeCheked, offideNote)

Здесь streetCheked, houseCheked, officeCheked - поля типа bool (= true, если соответствующие данные проверены).
streetNote, houseNote, officeNote - примечания к соответствующим полям

Словесное описание:
- организация может занимать целое здание (в этом случае адрес конкретизируется до номера здания) либо располагаться в одном из офисов здания (в этом случае адрес конкретизируется до номера офиса)
- организация может иметь 3 адреса: фактический, юридический, почтовый
- адрес здания конкретизируется до номера здания
- каждый адрес организации (фактический, юридический, почтовый) территориально связан с одним из зданий
- каждое здание может иметь адрес, а может и не иметь (если адрес неизвестен либо ещё не введён в БД)
- каждый адрес каждой организации может быть задан, а может быть НЕ задан (если адрес неизвестен либо ещё не введён в БД)
- каждое поле адреса в отдельности может иметь разные cheked-статусы (например, streetCheked = false, houseCheked = true)
- если несколько организаций расположены в одном здании, то поля streetCheked, houseCheked для каждой из организаций могут быть разные
- в каждый момент времени организация может иметь некоторый адрес, но при этом соответствующее здание в БД может отсутствовать (например, в справочнике может присутствовать московская организация, тогда как здания в БД загружены только для Новосибирска)

Как организовать связь всех этих сущностей ?
Предлагаем варианты.

Cyrax_02,

Organization 1 : 0..N Address
Address 0..1 : 0..N Building

ну в смысле:

Organization 1 : 0..N Address
Address 0..N : 0..1 Building

Cyrax_02

Имеются следующие сущности: Организация (id, ...) Здание (id, ) Адрес (id, street_id, streetCheked, streetNote, houseNum, houseCheked, houseNote, office, officeCheked, offideNote) Здесь streetCheked, houseCheked, officeCheked - поля типа bool (= true, если соответствующие данные проверены). streetNote, houseNote, officeNote - примечания к соответствующим полям Словесное описание: 1 - организация может занимать целое здание (в этом случае адрес конкретизируется до номера здания) либо располагаться в одном из офисов здания (в этом случае адрес конкретизируется до номера офиса) 2 - организация может иметь 3 адреса: фактический, юридический, почтовый 3 - адрес здания конкретизируется до номера здания 4 - каждый адрес организации (фактический, юридический, почтовый) территориально связан с одним из зданий 5 - каждое здание может иметь адрес, а может и не иметь (если адрес неизвестен либо ещё не введён в БД) 6 - каждый адрес каждой организации может быть задан, а может быть НЕ задан (если адрес неизвестен либо ещё не введён в БД) 7 - каждое поле адреса в отдельности может иметь разные cheked-статусы (например, streetCheked = false, houseCheked = true) 8 - если несколько организаций расположены в одном здании, то поля streetCheked, houseCheked для каждой из организаций могут быть разные 9 - в каждый момент времени организация может иметь некоторый адрес, но при этом соответствующее здание в БД может отсутствовать (например, в справочнике может присутствовать московская организация, тогда как здания в БД загружены только для Новосибирска) Как организовать связь всех этих сущностей ? Предлагаем варианты.

Для нормального проектирования потребуется уточнение "словесного описания", в части:

1. "Занимать ..." и "Иметь ... " Должно ли быть взаимоувязано между собой "обязательно"? Потому что первое можно связывать с Сущностью Здание (с точностью до "офиса"), а второе с Сущностью "Адрес", при этом первое со вторым в рамках "Организации" может и не быть связанным... или оно ДОЛЖНО быть связано?

Возможно ли наличие Организации, занимающей 2 офиса в здании по конкретному адресу (адрес здания - известен), но(!) тем не менее, не имеющей "фактического" адреса обитания?

Специально подобрал для Вас первый "спорный" момент, показав всю его избыточность... вот по каждому пункту своего словесного описания пройдитесь таким же гребешком и "причешите". Если останутся вопросы - выкладывайте и спрашивайте.

Если хочется, чтобы кто-то это сделал за Вас - пишите сколько стоит. :)

автор
Organization 1 : 0..N Address Address 0..N : 0..1 Building

avajdbc, т.е. ваш вариант не предполагает непосредственной связи Organization с Building ?
В этом случае связь Organization с Building будет устанавливаться путём сравнения адресов организации и зданий.

Здесь появляется такая проблема:
Возможны случаи, когда 2 здания в БД имеют один адрес:
- пристрой к одному из зданий = ул.Московская, 10/1 и соседний дом = ул.Московская, 10/1 (есть реальный пример)
- жилой дом имеет 2 пристроя с каждой стороны, при этом и сам дом и оба пристроя имеют одинаковый адрес ул.Московская, 10/1, но в БД в таблице building они представлены 3 разными записями.
В обоих случаях возникает проблема: с каким building'ом соотнести организацию с адресом ул.Московская, 10/1 ?

автор
1. "Занимать ..." и "Иметь ... " Должно ли быть взаимоувязано между собой "обязательно"? Потому что первое можно связывать с Сущностью Здание (с точностью до "офиса"), а второе с Сущностью "Адрес", при этом первое со вторым в рамках "Организации" может и не быть связанным... или оно ДОЛЖНО быть связано?

Нет, не обязательно. Для здания в БД может быть не указан никакой адрес (например, он неизвестен либо здание заброшено и официального адреса не имеет).

"Организация занимает здание/офис" и "организация имеет адрес" - не обязательно связаны. Т.к.:
- организация может иметь адрес, который точно известен. Но при этом здание с таким же адресом в БД может отстутствовать
- в БД для организации может быть задан ошибочный адрес (при streetCheked = False и houseChecked = False), при этом в БД может присутствовать здание с таким адресом (в этом случае фактически организация в этом здании не расположена)
- в БД некоторые дома могут иметь ошибочные адреса: например, здание/дом расположено между 2 улицами и к какой улице оно принадлежит точно неизвестно (при этом номер дома может быть известен). В этом случае улица может быть указана, а может быть и не указана (при этом streetChecked = False)

автор
Возможно ли наличие Организации, занимающей 2 офиса в здании по конкретному адресу (адрес здания - известен), но(!) тем не менее, не имеющей "фактического" адреса обитания?

Полагаем, что 2 офиса в одном здании занимать не может. Либо одно здание целиком, либо 1 офис в здании.
Для организации, в реальности занимающая офис в здании, в БД фактический адрес может быть НЕзадан (например, неизвестен).

[quot Cyrax_02
Полагаем, что 2 офиса в одном здании занимать не может.[/quot]

Странное ограничение.

А два здания организация занимать может?

А здание, и офис в другом здании?

е
[quot Cyrax_02 Полагаем, что 2 офиса в одном здании занимать не может.[/quotе] Странное ограничение. А два здания организация занимать может? А здание, и офис в другом здании?

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