Структура базы данных: как лучше спроектировать эту проблему?

У меня есть пользователи, у которых есть несколько объектов, и они могут загружать изображения для этих объектов. Каждый объект имеет несколько элементов. Фотографии, загруженные пользователем, могут быть назначены этим элементам. Дело в том, что один объект может иметь один конкретный элемент более одного раза.

Приведем пример: объекты — это автомобили, а предметы — это сиденья, окна, двери и т. д. В автомобиле может быть 5 мест, но все сиденья — это один и тот же предмет. Однако описание изображения должно по-прежнему быть «место 1», «место 2» и т. д., и пользователь также может загрузить несколько изображений для места 2.

До сих пор у меня есть следующие таблицы:

объекты: идентификатор, имя

элементы: идентификатор, имя

assigned_items: id, object_id, item_id, количество

изображения: id, object_id, item_id

Как бы вам лучше решить эту проблему?

Причина, по которой я использую количество, заключается в том, что если меняется тип предмета, то, скорее всего, всех предметов. Например. 4 сиденья могут стать 4 колесами и т. д. Итак, если бы для каждого назначенного_элемента была строка, скажем, сиденье1, сиденье2, сиденье3 и т. д., то это было бы сложнее изменить, не так ли?


database database-schema relational-database database-design database-normalization
person Chris    schedule 17.03.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Взгляните на эту модель:

введите здесь описание изображения

Это позволяет вам:

  • Соедините несколько элементов с несколькими объектами (благодаря таблице OBJECT_ITEM).
  • Соедините один и тот же элемент несколько раз с одним и тем же объектом (благодаря полю OBJECT_ITEM.POSITION).
  • Подключите несколько изображений к соединению объект-элемент (благодаря таблице OBJECT_ITEM_IMAGE). Итак, мы подключаемся к соединению, а не напрямую к элементу.
  • Назовите изображение, относящееся к связи объект-элемент (благодаря полю OBJECT_ITEM_IMAGE.IMAGE_NAME), а не только к изображению.
  • Убедитесь, что имя изображения уникально для соединения объекта с элементом (благодаря ограничению UNIQUE "U1").

ПРИМЕЧАНИЕ. Эта модель может быть упрощена, если отношение ОБЪЕКТ:ЭЛЕМЕНТ равно 1:N вместо M:N, но ваша собственная попытка модели предполагает, что это M:N.

ПРИМЕЧАНИЕ. Чтобы подключить изображение напрямую к OBJECT (вместо OBJECT_ITEM), вам потребуется дополнительная таблица ссылок (OBJECT_IMAGE) «между» OBJECT и IMAGE.

Пример данных:

OBJECT:
    Car

ITEM:
    Seat

OBJECT_ITEM:
    Car-Seat-1
    Car-Seat-2
    Car-Seat-3
    Car-Seat-4
    Car-Seat-5

OBJECT_ITEM_IMAGE:
    Car-Seat-1-Image1 "Seat1 Image"
    Car-Seat-2-Image1 "Seat2 Image"
    Car-Seat-2-Image2 "Seat2 Alternate Image"
    Car-Seat-3-Image1 "Seat3 Image"
    Car-Seat-4-Image1 "Seat4 Image"
    Car-Seat-5-Image1 "Seat5 Image"

IMAGE:
    Image1
    Image2
person Branko Dimitrijevic    schedule 18.03.2012

arrow_upward
1
arrow_downward

Если вы на самом деле не имеете в виду, что элементы могут принадлежать нескольким объектам, использование assigned_items бесполезно. Если я вас правильно понял, вас больше всего беспокоит то, что иногда у вас есть изображения, являющиеся частью предмета, так как же вы описываете изображение?

Вот что я предлагаю:

ОБЪЕКТ: идентификатор, имя

ПУНКТ: идентификатор, имя, количество, object_id

IMAGE: id, name (null), object_id (null), item_id (null)

Если ваша СУБД поддерживает ограничения, настройте ограничение на IMAGE для принудительного применения одного или другого из object_id или item_id (но не обоих). Это позволяет определить изображение как для элемента, так и для объекта в целом.

Когда вы запрашиваете имя изображения, вы должны использовать функцию COALESCE (или эквивалент вашей БД), чтобы выбрать имя переопределения изображения (если оно существует) или имя объекта/элемента (если переопределение не существует).

person Joel Brown    schedule 18.03.2012
comment
спасибо за ваш ответ ... чего я не понимаю, так это того, что если изображение назначено не элементу, а самому объекту? в изображениях нет отношения к объекту, не так ли? как будто предмета нет, я не могу ни к чему привязать изображение... - person Chris; 18.03.2012
comment
@Chris - я обновил свой ответ, чтобы разместить дополнительную информацию в вашем комментарии. - person Joel Brown; 18.03.2012
comment
да, это хорошая идея, Джоэл.. однако теперь у вас есть object_id в элементе и в изображении... именно поэтому я не хотел его использовать.. однако спасибо за ваши усилия! :) - person Chris; 18.03.2012
comment
@ Крис - я не понимаю, что тебя беспокоит. Вам нужен object_id в ITEM, потому что в противном случае невозможно узнать, какие элементы принадлежат каким объектам. У вас есть и item_id, и object_id в IMAGE, но вы используете только один или другой, в зависимости от того, к чему относится изображение. Невозможно представить информацию, которая, как вы утверждаете, нужна с меньшим количеством столбцов или меньшей избыточностью. Пожалуйста, объясните, почему вы считаете мой ответ проблематичным. Ответ, который вы приняли, более сложен и подвержен ошибкам, чем то, что я предлагаю. Скажите, пожалуйста, как места могут применяться к нескольким автомобилям? - person Joel Brown; 19.03.2012
comment
Если у вас есть object_id в элементах и ​​на изображении, мне это не кажется полностью лишним. Но я предполагаю, что Бранко имел в виду дополнительную таблицу с этими отношениями. Мне понравилось решение, потому что теперь у меня есть ИЗОБРАЖЕНИЯ: идентификатор, назначенный_кому (например, 0=объект, 1=элемент), назначенный_ид (либо объектный_ид, либо элемент_идентификатор, в зависимости от значения назначенного_кому). Другими таблицами являются OBJECTS, ITEMS и ITEMS_ASSIGNED (отношение между ITEMS и OBJECTS, поскольку объекты могут иметь любое количество (а также несколько) элементов)... каково ваше мнение по этому поводу? в любом случае, +1 за все ваши усилия! еще раз спасибо! - person Chris; 19.03.2012
comment
@Chris - Спасибо за +1. Причина, по которой мне не нравится ITEMS_ASSIGNED, заключается в том, что он не только позволяет объекту иметь много элементов, но также позволяет использовать элемент совместно со многими объектами. Основываясь на примере, который вы привели о том, что может быть объектом и каким может быть предмет, это не имеет для меня смысла. Может ли место действительно принадлежать разным автомобилям? Я бы так не думал. Кроме того, OBJECT_ITEM_IMAGE не позволяет вам иметь изображение всего объекта, поскольку item_id является частью PK, поэтому невозможно иметь значение null для item_id. У вас может быть три изображения стула №2, но не может быть одного из стульев 3 и 4. - person Joel Brown; 19.03.2012
comment
@Chris - Извините, закончились символы и место, и в спешке я слишком много отредактировал. Что мне нужно было добавить относительно OBJECT_ITEM_IMAGE, так это то, что, конечно, вы можете иметь изображение нескольких элементов, всех элементов в объекте и даже элементов в нескольких объектах — что является проблемой, не так ли? Однако наличие более одного элемента на изображении требует нескольких записей, чего, я думаю, вы хотели избежать, насколько это возможно. Таким образом, решение Бранко удовлетворяет одну потребность и упускает несколько других. - person Joel Brown; 19.03.2012
comment
Что ж, ты прав, Джоэл ... у тебя не могло быть изображения стульев 3 и 4, даже не думал об этом, хотя это было бы очень редко, ты прав, и с этим не очень хорошо обращались бы. С другой стороны, место может и обычно принадлежит нескольким автомобилям. Это похоже на то, как место продукта xy используется в автомобиле1 и автомобиле5. Это хорошо, так как этому сиденью назначены функции (например, сиденье xy имеет подогрев), и, возможно, через 2 года у сиденья xy тоже будут новые функции, которые затем автоматически назначаются также car1 и car5. - person Chris; 19.03.2012