Всем привет!
Выражаю благодарность за внимание к данному топику и буду очень признателен за информацию по такому вопросу.

Имеется сущность "Товар", "Книга операций с товарами" и "Поставщик товара".
Отношение между сущностями "Товар" и двумя другими - 1:N.
В системе предусмотрена следующая логика при удалении товара из базы.
При удалении записи из таблицы "Товар" удаляются все связанные записи из таблицы "Поставщик товара".
При этом если имеются связанные записи в "Книга операций с товарами" - то товар удалить нельзя (см. иллюстрацию во вложении).
Как описать данную логику при помощи CASE средств?

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

Galogen, спасибо.
1. Что на Ваш взгляд требует изменения?
2. Буду признателен за ссылку. Не нашёл этих обозначений.

Galogen, спасибо.
1. Что на Ваш взгляд требует изменения?
2. Буду признателен за ссылку. Не нашёл этих обозначений.

Попробуйте скачать Erwin - там есть community edition и есть способ отображения этих процедур. В целом они стандартные:
I:R - insert restrict
D:R - delete restrict
U:R update restrict
если R заменить на C- это будет каскадная процедура - то что нужно для первого вашего требования
Там есть и другие правила
Set null
set default

а так вообще 6 правил рассматриваются
3 со стороны родителя (вставка, обновление и удаление)
3 со стороны дочерней сущности

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

Теперь понятно! Раньше все эти правила приходилось запоминать, теперь смогу наносить обозначения и работать по схеме.
Модель неполная, приведена для примера.
Благодарю за помощь!

Модель неполная, приведена для примера.
Благодарю за помощь!

Ясно. Рад был помочь.

Mixailo

Сбоку и не об этой модели...

У Вас имеется ошибка ещё на уровне предметной области, а соответственно и архитектуры.
Поставщик - это поставщик. Юридическое лицо или ИП со своим набором свойств и методов.
Товары же, поставляемые одним поставщиком стоит выносить в отдельную сущность - "Спецификация" (прайс-лист, контракт, как угодно). В реальности у Вас с одним поставщиком может быть один договор на одно Ваше юр.лицо, а в этом договоре - несколько спецификаций на разные случаи жизни, в которых встречается один и тот же товар).

О диаграмме.
На диаграмме классов Вы пишете связи между сущностями. Вы уверены, что на ней же нужно обозначать ограничения?
Проверка условий при удалении - это уже одно из действий метода класса. Зачем её наверх тащить ?

Андрей,
Благодарю Вас за интерес к данной теме.

Таблица "Поставщик товара" используется для примера, хотя есть и реальный экземпляр такой таблицы в Microsoft Dynamics NAV. Там она называется Item Vendor. Полагаю, в неё можно заводить перечень одобренных поставщиков рассматриваемого товара, который может не совпадать с перечнем всех поставщиков, у которых данный товар имеется в прайс-листе.

Соглашусь с Вами, проверку при удалении можно указывать в методах класса. Это будет хорошим вариантом.

Mixailo

Моё знакомство с Ахапкой закончилось достаточно давно, ещё во времена 3й версии, так что точно сказать не могу, но ...
что-то мне подсказывает, что  Item Vendor - это не собственно ракурс Поставщика, а скорее ссылочная таблица для записи данных о конкретной партии (поставке, документе ...).

Пример. На основе реального.
Есть производитель. У него по России N заводов.
Есть сеть магазинов. У неё по всей стране N+1 магазинов
Так вот, поставщиком для этих N+1 магазинов будет не сам производитель. Это не оправдано никак с точки зрения логистики.
Поставщиков будет несколько - обычно вокруг каждого завода определяется регион, в котором некий местный поставщик будет приводить товар в местные магазины.
Товар один и тот же по факту. Разве что штрих-коды отличаться будут.

И вот на случай списания или возврата товара поставщику и может пригодиться ссылка на поставку.

Смотрите сами короче.

Андрей,

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