Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II Cardinality Dilemma

 
Chris Bicnal
Ranch Hand
Posts: 99
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,

I'm working through my class diagram and am struggling a little bit - I know I should be mapping out business logic, but with the inclusion of entity beans in my diagrams I find myself crossing the line between the logical design of the application and an ERD.

One of the questions that I have is around the cardinality of the business domain model. If I'm understanding it correctly the only way I can make sense of the provided cardinalities is with data duplicated in multiple tables. This doesn't sit well with me, so I'd like to change the cardinality to normalize the design such that there won't be any duplicated data stored.

I'm working on Retire Early Inc.

Has anyone else come across this problem? If so, am I on the right lines?

Finally, how have people stayed on track with the class diagram regarding business logic and avoided writing an ERD?

Thanks,

Bic
 
Aditya Kumar
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Does the Cardinality depicted in the business domain model go well with the Use Case scenarios? If yes, then you should not try to change it.
In my opinion, the use case scenarios are the things that you should stay true to. If there is a "marginal" change in the cardinality because you have to suit your use case, then you can always justify that change in the notes, saying that you've stayed true to the use case scenario. But remember - a marginal change and not a big one.

Thanks
Aditya
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic