对于我需要完成的任务来说，这是正确的架构设计吗？
当铺商业模式：
CLIENTES（客户表）、LOTES（批次表）、ARTICULOS（物品表）和 TRANSACCIONES（交易表）。
我定义批次表的原因是，当客户典当或出售物品时，当铺将所有这些物品分组为一组，计算总贷款或购买金额，将这些值存储在一笔交易中，并打印带有所有物品描述的票据。项目及总金额。所以我想说的是，如果客户拖欠利息或不赎回典当，那么客户将没收所有物品，当铺可能会选择将某些物品出售给黄金精炼厂和/或将其他非黄金物品转移到库存中以出售给公众。换句话说，我希望能够对每个项目进行突破性爆炸。
上述 ER 足以满足此功能吗？
Pawnshop business model:
CLIENTES (customer table), LOTES (lot table), ARTICULOS (item table) and TRANSACCIONES (transaction table).
The reason I defined a lot table is because when customers pawn or sell items, the pawnshop groups all these items into one lot, calculates the total loan or purchase amount, stores these values under one transaction and prints the ticket with a description of all the items and total amount. So I want the ability to say, if customer defaults on interest payments or does not redeem pawn, then customer forfeits all items and pawnshop may choose to sell some items to gold refinery and/or transfer other non-gold items to inventory to sell to the public. In other words, I want the ability to do a break-out explosions of each item.
Would the above ER be adequate for this capability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从逻辑模型的角度来看，您可能不希望批次上有 store_id（因为它来自客户）或交易或物品（因为它们通过批次和客户获得）。在物理层面，您可能将这些作为属性（称为非规范化），您可能会面临数据显示的风险，例如，LOT 1234 位于客户 C12 和商店 S1 上，而客户表的 C12 位于商店 S2 上。
当然，您可以允许史密斯先生在一家商店典当一件物品，但在另一家商店付款。或者，一件物品可能在一家商店被典当，但由于安全或空间原因而实际转移到另一家商店。如果是这样，那么在这些实体上拥有不同的商店 ID 是合适的。
然而，这与“商店”作为客户的属性并不相符，因为这意味着他们只与一家商店有关系。
另请考虑如果 MR P BROKER 拥有 3 家商店，但决定关闭其中一家并将业务转移到其他商店之一，会发生什么情况。您需要合并商店，但您是否更新所有交易、物品和批次（包括“进行中”和已兑换的交易）的商店 ID，还是保留原始商店 ID？
另一个常见的数据建模问题是识别客户。史密斯先生是一位顾客，史密斯夫人是另一位顾客，还是史密斯先生和史密斯夫人可以是同一顾客的“一部分”？如果史密斯先生典当了某物，史密斯夫人可以赎回吗？我在想家庭争吵，有争议的传家宝……也许她不能赎回它，但可以用它来付款。
如果一件物品（例如手表）包含在一个批次中，然后兑换，然后包含在不同的批次中，它是否会获得不同的 item_id ？
From the point of view of a logical model, you probably don't want store_id on the lot (as it comes from the customer) or the transactions or articles (as they get it through the lot and customer). At the physical level you might have those as attributes (called denormalisation), you have the risk of data showing, for example, LOT 1234 being on CUSTOMER C12 and at STORE S1, while the customer table has C12 being at store S2.
Of course it is possible that you allow Mr Smith to pawn an item at one store but make payments on it at another. Or perhaps an item might be pawned at one store but physically relocated to a different one for security or space reasons. If so, then it is appropriate to have distinct store ids on these entities.
However that doesn't sit comfortably with the 'store' being an attribute of the customer, since that implies they have a relationship with only one store.
Also consider what happens if MR P BROKER has three stores, but decides to close one and move the business to one of the others. You need to merge the stores but do you update the store id on all the transactions and articles and lots (including ones that are 'in progress' and those redeemed) or do you leave them with the original store id ?
Another common data modelling issue is identifying customers. Is Mr Smith one customer and Mrs Smith another, or can Mr and Mrs Smith be 'parts' of the same customer ? If Mr Smith pawns something, can Mrs Smith redeem it ? I'm thinking family squabbles, disputed heirlooms.... Perhaps she can't redeem it, but can make payments on it.
If an item (eg a watch) is included in one lot, then redeemed, then included in a different lot, does it get a different item_id ?
当客户购买向公众提供的物品时，这算不算交易？或者您的数据库仅跟踪有关批次的交易？
某个项目可以存在于您的系统中而不属于任何批次吗？您无法在您提出的 ER 模型中表达这一事实。
您的 ER 模型没有显示任何多对多关系。这让我很怀疑。我从来没有在当铺工作过，所以我不能确定。但我见过的所有其他企业数据库都至少具有一种多对多关系。有时，关系被视为一个实体，并以自己的盒子出现。但那个盒子将位于多个关系的“无限”端，这是我在你的图表中看不到的。
布埃纳苏尔特。
When a client buys an article offered to the general public, is that a transaction? Or does your database only track transactions about lots?
Can an item exist in your system without being part of any lot? You can't express that fact in the ER model you've presented.
Your ER model doesn't show any many to many relationships. That makes me suspicious. I've never worked in a pawnshop, so I can't say for sure. But every other enterprise database I've ever seen has at least one many-to-many relationship. Sometimes a relationship is treated as though it were an entity, and appears with a box of its own. But that box would be on the "infinity" end of more than one relationship, something I don't see in your diagram.
Buena suerte.