Open durinfab opened 3 years ago
Here is my feedback of your design model.
What about making an enumeration for InstrumentType so that member can select from the list? Also, maybe the multiplicity for instrument would be one to many because each member should play at least one musical instrument in this club.
For mailAddress, shouldn't it be mandatory and multiplicity as 1?
I guess the reason why the data type of practicingDate is String not Date is that the practice date of each ensemble can be for example, every Monday at 6pm and the specific date need to be changed every week. Is it right?
As I wrote in the information domain model, the participation of each ensemble into the event is not mandatory. Only when there's a meeting for each ensemble, the ensemble participates in the event.
Can't the data type of personInCharge of 'Event' be 'Member', not String type? Because the person in charge of the event is also one of the members in the club.
I guess the number of participants in the event can be 0 if no one wants to participate.
I hope this can be helpful for you :)
Thank you for the feedback! We added an instrument enum. We also fixed the mailAddress
As I wrote in the information domain model, the participation of each ensemble into the event is not mandatory. Only when there's a meeting for each ensemble, the ensemble participates in the event.
Exactly, we modelled a situation where there has to be at least one ensemble to take part in an event, as events usually are made for ensembles and not single people or other groups.
Can't the data type of personInCharge of 'Event' be 'Member', not String type? Because the person in charge of the event is also one of the members in the club.
This would be problematic. For example: There is a concert planned by a person. This person is not neccessarily part of an invited ensemble or any other music group.
I guess the number of participants in the event can be 0 if no one wants to participate.
That is true. Thanks for the help!
This is the new diagram:
I can see only instrument part should be changed. First, the multiplicity could be '0 to many' or 'one to many'. For example, there would be a person who can play both of the guitar and lute. And I guess the range of instrument would be InstrumentEL not String type. Other things look fine :)
We improved the instrument part. We decided to use a "0 to many" multiplicity because i.e. the manager of the ensemble must not necessarily play an instrument.
Yeap that would be nice
This issue includes our first concept of the information design model
Feedback is appreciated!