Предположим, необходимо изучить питание каких-л. животных. Известно, что некоторые могут питаться чем-то одним, а другие - всеядные. Например, обезьяны могут есть мясо (неважно каких животных), грибы (неважно какие) и растения. Но в отношении растений требуется более подробная информация. Дело в том, что у разных растений пищевую ценность могут представлять разные органы этих растений (листья, корни, плоды) и требуется информация какие именно. Задача - определить схему пищевых ресурсов для обезьян в базе данных.
Вариант: создаем таблицы ОБЕЗЬЯНЫ, РАСТЕНИЯ, ОРГАНЫ (растений), РАСТЕНИЯ_ОРГАНЫ (связующая), ГРУППЫ ПИЩЕВЫХ РЕСУРСОВ. А вот как теперь организовать соединительное звено между ОБЕЗЬЯНАМИ и имеющимися таблицами, чтобы выполнить поставленную задачу? Вводить еще какие-н. промежуточные таблицы?

To proposed amendment:
Нет, я все-таки полагаю, что иерархическая таблица с животными должна существовать сама по себе, а должна быть связующая таблица между животными и кормовыми ресурсами типа: ID_вид_животного - ID_кормового ресурса. Таким образом, мы свяжем животных и ресурсы М:М, что верно.

To Schtock:
Значит, если я правильно понял, Вы предлагаете сделать одну таблицу для пищевых ресурсов (иерархическую) и отображать ее деревом? Хорошо, но, здесь как бы нарушается нормализация, т.е. для каждого растения мы будем заносить в эту таблицу органы, которые, в общем-то, примерно одни и те же у всех растений (практически у всех есть корни, стебли, листья, плоды) или это ничего? А кроме того, я хотел сделать сами растения деревом (классификацию) и их органы туда не очень вписываются…

Не могу я "забыть" про растения! Дело в том (это моя вина, я не сразу обрисовал все задачи), что связь между растениями, которые выступают в качестве пищевых, и животными должна анализироваться не только как между конкретными видами с той и другой стороны, но и на более высоких таксономических уровнях (например, семейства). Таким образом, вытекает необходимость поместить растения в отдельную иерархическую таблицу, т.к. загонять ее в таблицу "Пищевые ресурсы" неразумно и противоречит логике.
Каким-то образом нужно реализовать такую взаимосвязь между таблицами (существующими или добавленными), чтобы в зависимости от выбранной группы в таблице КОНКРЕТНЫЙ_ПИЩЕВОЙ_РЕСУРС выбирался этот самый ресурс. Т.е. выбираем в поле "Код группы" - "Растительная" и в поле "chrКонкретный пищевой ресурс" получаем возможность выбора сочетания "Орган растения - растение" из таблицы "РАСТЕНИЯ_ОРГАНЫ". Соответственно выбираем "Животная" - выбираем ресурсы животного происхождения и т.д. Сложность еще и в том, что животные бывают каннибалами (обезьяны вряд ли, но кроме обезьян могут быть и другие), т.е. ресурс как бы замыкается на его потребителях, т.к. это один и тот же объект реального мира.
Налицо четкие реляционные связи, которые никак не получается увязать в стройную схему. Уже подумывал о введении "лишних" таблиц с теми же объектами, только выступающими теперь в качестве ресурсов, а не иерархическими-таксономическими. Тогда вылазит проблема целостности и нормализации... Не знаю, что придумать, уже крышу рвет.

Т.е., если я правильно понял, Вы предлагаете сделать так:

Не всегда удобно картинки выкладывать, они иногда большего размера, чем допускается. Таблицы Растения, Пищевые ресурсы и Обезьяны - иерархические.

А вот наполнение таблицы Пищевые ресурсы

Ну вот как-то юмористическую составляющую я никогда не оценивал. Область применения - БД для личного пользования. А по делу-то будут соображения?

Ух ты! Пошел за пол-литрой, разбираться :)

А такие штуки с помощью UML рисуются, да? Я профан в этом вопросе.

Shtock, прошу прощения, был в командировке, не мог ответить. Я понял, что ты что-то грандиозное придумал, но что именно - понять ума не хватило и вдобавок я не знаю, какие стрелки что обозначают. Буду очень признателен, если ты "на пальцах" пояснишь свою схему.

Нет, все равно понимания нет...
Классификатор - это таблица? Иерархическая? Рядом с ней 3 классификации - все в одной таблице?
В общем, если несложно, поясни попроще, я не программист и мне во все эти классы въезжать сложно.

А как можно 3 классификации запихнуть в одну таблицу? Тогда ведь у них должно быть и что-то объединяющее их? А то не будет общего корня.

Ну вот что я пока надумал, если что не так - поправьте меня:
1. "Отношение между классами" – это, как я понимаю, отдельная таблица, в которой связываются записи "животное" – "объект из какой-л. иерархии" (растение, др. пищевой субстрат, м.б. и животное в случае хищничества и даже тот же самый вид животного в случае каннибализма) из "Классификатора"? И именно поэтому от "Классификатора" две стрелки к "Отношению между классами", т.е. "Классификатор" замыкается сам на себя?
2. Или эта связь "животное" – "объект" в таблице "Набор для класса 2"?
Тип отношения – это хищник, травоядное, многоядное? Если так, то отдельно, наверное, выделять этот класс смысла не имеет, а лучше в глобальный классификатор добавить поле "Группа" (животная, растительная, другая) и анализировать связку "животное" – "объект из какой-л. другой иерархии" по этому признаку?
Тогда достаточно двух таблиц – "Классификатор" и "Связка животное – объект". Эти связки можно потом анализировать отдельно по признакам группы и ID объекта. Если "объект" – растение, то "животное" – травоядное. Если "объект" – животное, то "животное" – хищник (ID "объекта" = ID "животного" – каннибал). И т.д.
Плюс глобального классификатора в том, что мы не плодим лишние сущности для разных объектов? Минус: в этой иерархической таблице органы растений становятся частями объекта растения – по смыслу правильно, но нарушается нормализация. Кроме того, для них значения поля "статус таксона" становятся NULL, равно как и для других пищевых субстратов типа йогурт и т.п. Тоже не есть хорошо.
А если так: делаем иерархические таблицы "животные", "растения", "всякие другие объекты" и устанавливаем связи между ними отдельно? Т.е. будут также таблицы "животные как пищевой субстрат", "растения как пищевой субстрат ", "всякие другие объекты как пищевой субстрат ". Какие минусы такого подхода кроме бОльшего числа сущностей? Плюс в том, что не придется переделывать существующую таблицу с животными, а также переписывать код работы с ней. Хотя это, конечно, моя вина – надо сначала грамотно проектировать, а потом реализовывать.
И вот еще сложность – как-н. можно реализовать такое, например, выражение: "поедает многие травянистые растения"? Или это в принципе невозможно из-за неопределенности определения, сорри за тавтологию?

Shtock, особенно не усердствуйте (http://www.sql.ru/forum/actualthread.aspx?tid=367773), вы нужны народу!

Под "замыкается сам на себя" я и подразумевал рекурсивную ссылку одних объектов Классификатора на другие через таблицу "Отношение между классами".
На группу "Многие травянистые" я не могу сослаться в том варианте, который предлагается, т.к. травянистые – это атрибут растения (объекта), а сослаться надо на объекты и какие конкретно - неизвестно.
Вот что я еще надумал: варианты с применением классификатора и без такового.
В схеме с классификатором есть таблицы "Группы" (животная, растительная и т.д.), таблица "Тип отношения" (поедает, живет на …, симбиоз с … и т.д.). Специфичные таблицы типа "Орган растения" входят в один набор (для растений), неспецифичные типа "Биотоп" могут входить в несколько наборов.
Что мне не очень нравится в идее глобального классификатора – это попытка запихнуть в одну таблицу несколько разных сущностей с совершенно различными атрибутами. Ведь все учебники говорят, что в таком случае их нужно выделять в свои таблицы?
Вариант с классификатором:

Еще вариант с классификатором:

И без классификатора - наиболее понятный для меня вариант, который я предложил в посте от 24 ноября. Прошу высказать "за" и "против" каждого варианта. Вот этот последний - сильно неправильный?

А может еще кто-н. пока выскажется?

Или я чего-то не понимаю? Как это "Вы почему-то помещаете в него какие-то растения, животные и др."? Так Вы же сами предложили : "А сложите все в одну таблицу (грубо говоря,таблица объектов зоопарка),раз у Вас и сами животные будут ресурсы и сделайте для них отдельный классификатор". Я так понял, что все объекты окружающего мира, коль скоро они могут являться потребителями и/или поставщиками ресурсов, нужно занести в одну таблицу.
Атрибуты как раз есть, я же специально сделал на этом упор, когда предлагал вариант без универсального классификатора и мотивировал именно этим. Например, органы растений – это принципиально важно, скажем, животные едят плоды растения, но не едят листья, а другие животные едят именно листья того же растения. Если есть желание и интерес, я могу попробовать перечислить практически все атрибуты. Конечно, в варианте с классификатором органы растений становятся объектом, но все равно будут другие атрибуты, например, жизненная форма растений - трава, кустарник, дерево, что, согласитесь, уже никак не булевские признаки, и т.д.
По поводу "если же есть смысл быть вечно нужным" – если только самому себе, я уже писал, что база для личного пользования.

Эх... Я с периферии... Бываю в Москве раз в год, а в Питере и того реже. Но если соберусь - обязательно черкну. Да, было бы здорово пообщаться вживую. А также пивка попить :)
Не понял, что такое "ToКДЖ", а таблицы "растения", "животные" и т.д. появились в вариантах без классификатора - что в этом удивительного? В общем-то разные сущности, если проанализировать все атрибуты. Но, конечно, если от них абстрагироваться, то можно и в одну таблицу поместить. Впрочем, если абстрагироваться абсолютно, то база вообще будет из одной таблицы состоять :) Я в поиске золотой середины и, надеюсь, Вы мне в этом поможете.

Кто-нибудь еще может высказать свои соображения?