Система, которая отслеживает инвентарь с таблицей истории

Question

У меня есть система, которая позволяет участникам арендовать оборудование, и система должна иметь историю каждого предмета, который был арендован и кем.Система также должна отслеживать, у кого какое оборудование арендовано / арендовано, а также сортировать оборудование по типу, статусу, названию и т. Д. Наконец, она также должна отправлять уведомления по электронной почте об устаревшем оборудовании.

I 'Я пытаюсь понять отношения и как я должен моделировать это.На данный момент мои текущие таблицы и мышление выглядят примерно так:

Member Table:
Id (PK)
MemberId
FirstName
LastName
Email

EquipmentItem Table:
Id (PK)
EquipmentName
EquipmentType (FK)
EquipmentStatus (FK)
TotalQuantity
RemainingQuantity

EquipmentStatus Table:
Id (PK)
StatusName

EquipmentType Table:
Id (PK)
TypeName

EquipmentRentalHistory Table:
Id (PK)
MemberId (FK)
EquipmentId (FK)
CheckOutDate
ReturnedDate

1) Я хочу знать отношения между ними, будет ли история проката соотношением между многими из таблицы Member и таблицы EquipmentItem?

2) Будет ли таблица EquipmentItem иметь отношение один-ко-многим между статусом и типом, как я понимаю, это EquipmentItems может иметь много статусов или типов, но каждый статус или каждый тип может принадлежать только одному EquipmentItem.

3) Имеет ли смысл иметь поле количества в EquipmentItem, я раньше работал в продуктовом магазине, поэтому я основываю логику на штрих-кодах, где одни и те же продукты обычно имеют одинаковый штрих-код, например (Cheetos Puffчипы) все чипсы Cheetos Puff будут иметь одинаковый штрих-код, но будут иметь количественное значение.Или было бы лучше иметь каждый элемент уникальным, независимо от того, является ли он одним и тем же продуктом / моделью?

Моя логика будет такой:

1. член сдает в аренду систему
2. регистрирует его в таблице истории
3. Система затем проверяет, сколько из того же предмета было извлечено до сих пор, если, скажем, у нас есть общее количество 4 для этого предмета, и 3 участника проверили его
4. мы обновляем поле оставшегося количества на разницу, поэтому в этом случае система 1
5. может затем отследить, у кого что получено, вернув все записи с возвращенной датой, равной нулю
6. система будетзатем проверьте все записи с возвращенной нулевой датой, а затем укажите диапазон дат в проверенную дату, чтобы определить, не устарело ли оборудование
7. отправить уведомление на электронные письма участника, связанные с указанными записями, с шага 6

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

Answer 1

Чтобы ответить на ваши вопросы

1. Что касается моделирования в ERD, я не думаю, что оно квалифицируется как отношение «многие ко многим», скорее, «1005 *» - это его собственная сущность, которая имеет отношение «многие ко многим» с Member и EquipmentItem.

   «Многие ко многим» было бы больше похоже на то, что «a Member имеет доступ к 0 ... n EquipmentItems, и каждый EquipmentItem может быть доступен с помощью 0 ... n Members».

2. Я бы не согласился с тем, что это отношения один ко многим.

   Кислородный баллон и пара плавников могут быть классифицированы как «Подводное плавание» и иметь статус «Выписан».

   Вы можете иметь несколько тегов 'Scuba Gear' и назначать каждому уникальному тегу 'Scuba Gear' свой собственный EquipmentItem, но тогда вы просто будете создавать новые теги для каждого нового EquipmentItem, а не повторно использовать существующие из них.

3. Это действительно зависит от того, хотите ли вы точно определить, какую часть оборудования арендовал участник (возможно, что-то повреждено, вы можете отследить каждого, кто арендовал этот конкретный?). Если вы дифференцируете, то у каждого элемента будет свой ряд. Вам также следует добавить новый столбец в качестве внешнего идентификатора, но вести учет не нужно.

   Если вам все равно, то я бы оставил только total, но не available. Если вы сохранили столбец available, вам придется постоянно обновлять его всякий раз, когда что-то регистрируется в EquipmentRentalHistory. Это будет раздражать, если таблицы не синхронизируются. Вы можете просто запросить EquipmentRentalHistory для Id оборудования и подсчитать записи, где returnedDate IS NULL для количества оборудования, которое используется в настоящее время

Дополнительное примечание

Может быть, лучше иметь столбец «срок оплаты» в истории аренды, а не указывать дату в жестком коде на случай, если вы хотите изменить сроки оплаты. Таким образом, вы также можете предоставить расширения.