If you have any assumptions, please make them explicit. However, ensure that the logical dependencies remain intact. For instance, if the clinic decides to update how they store client numbers from 6 digits to 12 digits, this update should logically cascade on update. Similarly, if a surgeon leaves the clinic, the appointment table should not delete appointment history records. Instead, this change should be reflected in the services table, indicating that the surgeon no longer provides that particular service.
Hope this helps.
"Benjamin Oommen" <23*2*6*
8@s*u*e*t*u*a*e*u*a*> wrote:
> In our justifications for each entity's derivations, is it necessary/good practise to indicate an alternative representation that could be made as well? For instance, when posting uniqueIdentifierCode as a foreign key for the Service entity, I've reasoned that the foreign key should CASCADE ON DELETE to both maintain referential integrity and avoid a scenario where a surgeon who no longer works at the clinic is listed on an appointment, but I've found that the alternative (performing NO ACTION ON DELETE) would also be pertinent as an accidental deletion of a surgeon's identifying number, if cascaded in Service, could potentially cause a service to be listed without a surgeon (if only one surgeon provides that service) or at the very least with one fewer performing surgeon, which would be incorrect. Should I mention alternative derivations such as this or is that not necessary?
