Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Mixailo от 15 Сентября 2016, 13:39:23
-
Всем привет!
Выражаю благодарность за внимание к данному топику и буду очень признателен за информацию по такому вопросу.
Имеется сущность "Товар", "Книга операций с товарами" и "Поставщик товара".
Отношение между сущностями "Товар" и двумя другими - 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 магазинов будет не сам производитель. Это не оправдано никак с точки зрения логистики.
Поставщиков будет несколько - обычно вокруг каждого завода определяется регион, в котором некий местный поставщик будет приводить товар в местные магазины.
Товар один и тот же по факту. Разве что штрих-коды отличаться будут.
И вот на случай списания или возврата товара поставщику и может пригодиться ссылка на поставку.
Смотрите сами короче.
-
Андрей,
Не спорю, ситуации могут быть разные. Необходимость тех или иных таблиц определяется в каждом конкретном случае. Одним они нужны, другим - нет.