I was looking through your diagram here, as I am in the process of refining my model. I have noticed that you have applied a few "many to many" relationships in your diagram. I initially had these as well. As far as I understand, these need to be a "one to many" relationship. It is a sign of a missing entity. For example, you have employee to customer. Is there a missing entity of a "transaction" or something along those lines?
Thanks for your comments. I will have a look about the "many-to-many" relationships, and see which entities I can come up with to make them become "one-to"many".
Good points - for instance, there may be a 'support' entity between customer and employee (if I have understood what 'help' means in this context - it might just be another kind of transaction, so the relationship may be redundant).
Similarly, the connection between a customer and an item might be 'purchase' but perhaps it is just another kind of transaction. I'd be wary of overloading 'transaction' with too much, though. I'm guessing that, on the whole, it's not a term you'd find people in the system using. They might talk of purchases, receipts, visits, shopping baskets (carts?), etc.
I'm guessing that there's also a fair bit more involved with the More Rewards system than shown here, some of which might be necessary to include. One big one might be 'redemption' - presumably you need to know when points are used. Relatedly, there are likely to be a whole bunch of special offers that could apply to an item over time, which means that the points associated with a particular item will need to both change regularly and be recorded for historical purposes, which means they are not just an attribute of an item (or a transaction): I wonder whether 'offer' might be an entity? I'm not sure how that might relate to business rules for the awarding of points (are points given on dollars spent, or are they only ever on specific items? Are there standard awards for different types of item?). Would it ever matter to anyone to know at which cash register a purchase was made?
There may also be complexities due to the rather flexible way that people use their reward cards/accounts - they often apply them to the purchases of other people (common when someone has forgotten their card and uses that of the person next in line). This is particularly interesting because, presumably, the point of the rewards system is at least in part to track customer habits and patterns of purchase so, if they are getting rewards for other people's shopping, this will contribute to a very inaccurate picture, which might be particularly annoying for those who use the online history to construct shopping lists for deliveries etc: you'd suddenly find your list of options full of other people's purchase history.
I often find it useful when faced with a potentially complex system like this to simply list words that are found on documentation, web sites, etc to see where it takes me. Things like carts, redemptions, points, purchases, deals, etc might not all be entities in themselves but likely have to be dealt with somewhere in the system.
Comments
Hi Liliana,
I was looking through your diagram here, as I am in the process of refining my model. I have noticed that you have applied a few "many to many" relationships in your diagram. I initially had these as well. As far as I understand, these need to be a "one to many" relationship. It is a sign of a missing entity. For example, you have employee to customer. Is there a missing entity of a "transaction" or something along those lines?
Hi Timothy,
Thanks for your comments. I will have a look about the "many-to-many" relationships, and see which entities I can come up with to make them become "one-to"many".
Good points - for instance, there may be a 'support' entity between customer and employee (if I have understood what 'help' means in this context - it might just be another kind of transaction, so the relationship may be redundant).
Similarly, the connection between a customer and an item might be 'purchase' but perhaps it is just another kind of transaction. I'd be wary of overloading 'transaction' with too much, though. I'm guessing that, on the whole, it's not a term you'd find people in the system using. They might talk of purchases, receipts, visits, shopping baskets (carts?), etc.
I'm guessing that there's also a fair bit more involved with the More Rewards system than shown here, some of which might be necessary to include. One big one might be 'redemption' - presumably you need to know when points are used. Relatedly, there are likely to be a whole bunch of special offers that could apply to an item over time, which means that the points associated with a particular item will need to both change regularly and be recorded for historical purposes, which means they are not just an attribute of an item (or a transaction): I wonder whether 'offer' might be an entity? I'm not sure how that might relate to business rules for the awarding of points (are points given on dollars spent, or are they only ever on specific items? Are there standard awards for different types of item?). Would it ever matter to anyone to know at which cash register a purchase was made?
There may also be complexities due to the rather flexible way that people use their reward cards/accounts - they often apply them to the purchases of other people (common when someone has forgotten their card and uses that of the person next in line). This is particularly interesting because, presumably, the point of the rewards system is at least in part to track customer habits and patterns of purchase so, if they are getting rewards for other people's shopping, this will contribute to a very inaccurate picture, which might be particularly annoying for those who use the online history to construct shopping lists for deliveries etc: you'd suddenly find your list of options full of other people's purchase history.
I often find it useful when faced with a potentially complex system like this to simply list words that are found on documentation, web sites, etc to see where it takes me. Things like carts, redemptions, points, purchases, deals, etc might not all be entities in themselves but likely have to be dealt with somewhere in the system.