I'm learning about entity-relationship models (ERM) in school, and I understand the basic concepts of entities, attributes, and relationships. However, I'm confused about how to apply these ideas in practical scenarios without getting tied up in tables or normalization. For instance, I was watching a video on ERM that focused on these aspects in depth, which seemed contrary to what we've been taught.
Let's say a customer wants a trading system in a game where players can trade with shops. Here's a quick breakdown: both players and shops have money, and both own items. During a trade, a player can sell their items and choose which items to buy from the shop.
I can easily identify players and shops as entities, and their money as an attribute. Items are also entities. However, since players and shops might hold multiple items, I'm unsure how to represent this in my ERM.
For example, what about the trade itself? I've seen it represented variably as either a relationship or another entity. Should I model it as "Player Item" or as "Player Inventory Item"? Similarly, whether to use "Player Shop" or "Player Trade Shop" is unclear.
I hope that clarifies my confusion!
1 Answer
When creating your ERM for the trading system, think of entities as things that have a distinct identity, while relationships capture how these entities interact. Your Player and Shop are definitely entities. Items can also be treated as an entity since they each have properties beyond just being owned.
As for the trade scenario, it could be beneficial to treat the trade as a separate entity. This gives you the flexibility to include various properties related to the trade, like timestamps or trade amounts. You could model it something like this:
- Player Trade
- Trade Shop
- Trade Item.
This allows you to extend the model later if necessary. Just remember, the goal of ERM is clarity in conveying relationships and identities!
Exactly! By treating the trade as an entity, you can capture more complex behaviors and attributes related to the trading process, like the state of the trade (active, completed, etc.). That way, all your trading logic can be centralized and easier to manage.