Могут ли две сущности-потомка от одной сущности-родителя пересекаться в различных вариациях?

Question

[Filarru]

Оранжевые таблицы - независимые сущности.
Синие таблицы - зависимые сущности.
Сплошная линия - идентифицирующая связь.
Пунктирная линия - неидентифицирующая связь.

Возникают вопросы:
1. Не будет ли проблем при таком пересечении сущностей-потомков?
2. Есть ли проблемы с точки зрения нормализации?
3. Есть ли проблемы с точки зрения логической структуры БД?

Задуматься заставляют таблицы "Товар в магазине" и "Товар на складе" с включением FK "Зона поставок" в качестве неключевого атрибута.

Comments

[Everything_is_bad]

без описания предметной области трудно что-то советовать
1 чем магазин отличается от склада?
2. что делать если поставка будет между двумя складами или двумя магазинами?

[Shavadrius]

Может проще организовать словарь "Объекты" (ИД, Тип объекта (магазин, склад, пр.)) и в сам "Товар" включить столбец "На балансе на объекте" Объекты.ИД.

[Filarru]

Everything_is_bad,
У магазина свой уровень запасов, у склада свой. Магазин и склад строго физические объекты с разным координатами (адресами).
Также есть: множество магазинов, множество складов, множество товаров. И это все комбинируется между собой, для чего существуют промежуточные таблицы (синий цвет) из-за связи многие-ко-многим.

Второй вопрос не совсем понял. Могли бы разжевать? Так-то все поставки по запросу магазина в конкретной зоне (в каждой зоне может быть несколько складов и несколько магазинов, но всегда будет минимум 1:1).

[Filarru]

Shavadrius, к сожалению, уже не тот этап.
Это кусочек от всего проекта.

[Shavadrius]

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

[Filarru]

Shavadrius, это же учебные цели, а не живой проект.
Именно поэтому интересует теоретической вопрос на тему пересечения между собой двух потомков одного родителя.
А для киоска видимо придется отдельную таблицу заводить, особенно если киоск будет не один, а тоже некоторое множество и каждый со своим ассортиментом.

[Akina]

Filarru, я на 100% согласен с Everything_is_bad. Магазин и Склад - это одна и та же сущность "Место, где хранится товар". Да, они различаются атрибутами - но не более. То же относится и к "Товар на складе" и "Товар в магазине" - это по смыслу вообще не сущность, а Junction table, пусть и с дополнительными атрибутами. И в первую голову надо переделывать схему.

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

[Filarru]

Akina, а если учитывать, что магазин и склад - это совершенно разные физические объекты с совершенно разными задачи, где общее только то, что кокнретный товар только хранится? Тут всё общее заканчивается.
К тому же у нас есть:
1. Множество магазинов
2. Множество складов
3. Множество товаров
И, соответственно, куча комбинаций экземпляров одной сущности с двумя другими.

То, что "Товар в магазине" и "Товар на складе" - это промежуточные варианты, я изначально указал, тут проблемы нет.

А пересечение как раз в связи между, например, "Товар в магазине" и "Зона поставок".
Зоны разные территориально, в каждой свои магазины и склады.

[Everything_is_bad]

Filarru, поэтому "без описания предметной области трудно что-то советовать"

[SymphoGraph]

Мне это представляется примерно так:
"Магазин", "склад", "киоск" - это значения свойства "Tип объекта", которое принадлежит сущности "Объект".
Свойство "Адрес" так же принадлежит сущности "Объект".

Следующая таблица вероятно должна связать товар с объектом с помощью полей 'Что', 'Откуда', 'Куда', 'Когда' и 'Сколько'.
Именно она и несёт ответственность за то, куда молоко, а куда дрели. Так же по направлению из неё понятно где количество увеличилось или уменьшилось.

[Akina]

Filarru,

а если учитывать, что магазин и склад - это совершенно разные физические объекты с совершенно разными задачи, где общее только то, что кокнретный товар только хранится?

Да хоть в космос запусти. Это не влияет вообще ни на что. От слова "совсем".

у нас есть:
1. Множество магазинов
2. Множество складов
3. Множество товаров
И, соответственно, куча комбинаций экземпляров одной сущности с двумя другими.

Есть Товар. Наименование там, характеристики и прочее. Это не более чем описание. Есть квант (неделимая порция, единица) товара - вот именно они хранятся. И каждый квант Товара может соответствовать (храниться) только одному Месту хранения (складу или магазину). Так что никакой кучи комбинаций нет и в помине. Может для квантов Товара существовать надгруппа Партия товара - с целью уменьшения количества записей, но ценой усложнения логики контроля целостности.

Зоны разные территориально, в каждой свои магазины и склады.

Зона поставок вообще не сущность. Это атрибут места хранения - обычная справочная надгруппа.

[Filarru]

Akina, а как тогда работать с самими складами и магазинами? или они обособлено (без связей) будут в БД?

[Akina]

Filarru, ?? Шо б я понял, что такое "работать со складами и магазинами".

[Filarru]

Akina, имеется ввиду, что склад - это независимая сущность, аналогично и магазин.
И возникает потребность что-то поменять в такой сущности.
Т.е. мы никак товар, как квант, вообще не трогаем. Может даже склад будет совершенно пустой, там нет никаких товаров, но тем не менее, склад, как физический объект, и без всяких товаров обладает своими параметрами.

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

[Akina]

имеется ввиду, что склад - это независимая сущность, аналогично и магазин.

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

Например, для подсчёта общего количества некоего товара придётся делать два подзапроса с абсолютно одинаковой логикой - к магазинам и к складам,- потом объединять их через UNION, потом агрегировать, и от магазина/склада в итог не попадает ничего. И вот этот промежуточный UNION - ещё одно свидетельство в пользу того, что две разные таблицы хранят одну и ту же сущность.

Склад стал атрибутом товара, т.к. именно товар - это квант?

Есть сущность Место (склад или магазин). Есть сущность Товар. Эти две сущности связаны как M:N, то есть имеется juncion table.

Квант товара - это неделимый квантификатор атрибута Количество сущности Товар. Упаковка из 6 бутылок кваса. Мешок сахара весом 50 кг. И т.п. - то есть то, мельче чего экземпляр сущности Товар не дробится, и то, чем количество экземпляров учитывается. То есть атрибут сущности Товар, не подлежащий дальнейшему делению, его учётная единица в системе. То есть палетта с 20 мешками сахара - это не квант. Хотя 20 мешков сахара могут быть объединены в надгруппу Палетта - но она не будет являться экземпляром сущности Товар. Её могут поделить на две по 10 и отправить в разные магазины. А вот резать мешок и отсыпать полкило никто не станет.

на уровне сущностей обязана быть комбинация товара со складом

Пара (Товар-Место) - это связь типа M:N. Эта связь даже может иметь свои собственные атрибуты. И в этом случае она даже может интерпретироваться как самостоятельная сущность, хотя в данной схеме я полагаю это излишним.

[Filarru]

Akina,

"место, где находится товар"

Так нет никакого конкретного места, оно еще неизвестно, как неизвестно даже само наличие товара.
Это же просто абстрактные конструкции, а не конкретные данные.
Тогда уж правильнее:
"место, где может находиться экземпляр товар", верно?
Тогда это можно рассматривать как неключевой атрибут товара с типом enum или вроде того. Но это ладно.
Вопрос то как раз в том, по какой именно причине надо объединять склад с магазином? Я такого в даже очень крупных проектах еще не встречал.
Да, и тот и другой могут хранить товар. Но каждый из них может еще совершать множество других операций и далеко не только над товаром, но и какие-то свои собственные, свойственные только им самим.
Т.е. суть в том, что различий больше, чем одно. А вот общее там только одно.
Исходя из чего именно тогда предпочтение отдается именно единственному схожему признаку? И не было бы даже в таком случае целесообразнее вывести этот признак в отдельную таблицу и добавить её как внешний ключ в две предыдущие?

[Akina]

Filarru,

Так нет никакого конкретного места, оно еще неизвестно, как неизвестно даже само наличие товара.
Это же просто абстрактные конструкции, а не конкретные данные.

Вот вроде правильно сказал - это абстрактные конструкции... и прям вот тут же про какое-то конкретное место.

Я такого в даже очень крупных проектах еще не встречал.

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

У вас хоть склад и магазин - это одна сущность, но в зависимости от атрибута типа они будут отображаться на разных формах, в разном виде, с различным набором возможных операций... а вот перемещение товара в таблице будет выполняться совершенно одинаково, одним и тем же SQL-запросом с одними и теми же выражениями, и неважно, источник склад и получатель магазин, или наоборот.

UPDATE goods SET Place_ID = @new_place WHERE goods_id in ( {list} );

Answer 1

[Дмитрий Энтелис]

Вопрос изрядно холиварный.
То как сделали вы - имеет право на существование, но лично я бы по умолчанию сделал вместо "товар в магазине" и "товар на складе" одну таблицу вида:
- тип где (магазин, склад)
- код где
- код товара

Не забыть повесить на эти 3 поля уникальный индекс, а лучше даже сделать составной primary из 3х полей, без отдельного поля.

Из очевидных преимуществ:
- проще расширять (завтра у вас еще какой-нибудь "транзитный склад" появится)
- проще строить отчеты всякие по остаткам

PS Меня больше смущает таблица "зона поставок" - что это такое, почему она связывает и магазин и склад и товар?

Comments

[Filarru]

Условия такие:
1. Множество магазинов
2. Множество складов
3. Разные магазины и разные склады находятся в разных зонах территориально
4. Множество товаров

Т.е. имеем массу комбинаций трех сущностей.

Далее, конкретный магазин и конкретный склад могут быть в одной зоне поставок, а могут и не быть, но минимум 1:1, т.е. магазина без склада нет, как и склада без магазина.

Если проще, то представьте карту России. В разных местах разные магазины и разные склады. Один и тот же магазин может снабжаться разными складами, если они все в одной зоне поставок. Как-то так.

Также отмечу, что у промежуточных таблиц всегда составной PK, т.к. это нотация IDEF1X, и она вынуждает PK писать отдельно, а FK включаются в него как-бы по умолчанию, если они в зоне ключевых атрибутов. Тут ничего прям особенного, только выглядит криво, но суть все равно в составном PK.

[Дмитрий Энтелис]

Filarru, ok, я понимаю таблицу "зона поставок", но не понимаю зачем в "товар в магазине" / "товар на складе" хранится код зоны этой.

[Filarru]

Дмитрий Энтелис, товар поставляется со склада в магазин или наоборот (смотря что происходит), но магазин и склад имеют свой отдельный запас товаров. Только склад хранит, поставляет и забирает, а магазин хранит и продает.

[Дмитрий Энтелис]

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

[Filarru]

Дмитрий Энтелис, благодарю!