1

I think we agree that there is a correspondance between composition and delete cascading on one side and aggregation and nullify on delete on the other, in case we delete the whole instance in a whole / part relationship.

But what if there is no whole / part relationship between two classes:

I understand that we can only use composition and aggregation in cases where the whole / part hierarchy occurs: Car - Wheels, Apartment - Rooms and not in cases where this hierarchy does not occurs (e.g. Car - Driver classes).

So, how should we represent in UML this situation where there are deletion consequences in the database (nullify or cascading) but no "whole / part" relation?

Christophe
  • 68,716
  • 7
  • 72
  • 138
BIOS-K
  • 146
  • 1
  • 9
  • We do not agree. Aggregation which in UML terms is Shared Composition has no semantics from UML (see p. 110 of UML 2.5). Composition is Composite Aggregation in UML terms and is about reponsibility of lifetime. – qwerty_so Feb 22 '22 at 19:59
  • Use the X termination mark in sequence diagrams to visualize object destruction. – qwerty_so Feb 22 '22 at 22:14
  • I have slightly reworded the question, to clarify that you refer to delete consequences in the database (inferred from the cascade/nullify combined with the database tag) and look for the UML representation. I hope I got it right, but don't hesitate to edit or revert if needed. – Christophe Feb 22 '22 at 23:35

2 Answers2

1

Do we agree on the initial assumption?

The UML literature frequently refers to part-whole relationships regarding aggregation/composition. However, the definitions in the UML standard have evolved (see UML 2.5.1):

Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. (...)

  • Shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

  • Composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects.

Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.

In other words, there is no precise semantic specified for the "aggregation" (i.e. shared aggregation) that would make a difference from a simple association: shared aggregation is a modeling placebo.

The relationship between database constraints and UML modeling are therefore not as straightforward as you would assume.

Close match?

Moreover, there is no general one-to-one mapping between a database schema and an UML model. More than one database schema could be used to implement the same UML class diagram. And conversely, more than one UML diagram may represent the design that is implemented by a given database schema. So the best we can do here, is to consider close-matches.

In your database, the table with the FOREIGN KEY constraint would correspond to a potential component in a composition, or an element of a shared aggregation, or an associated instance in a simple association :

  • a ON DELETE CASCADE could help to implement a composite aggregation: it's the only way in SQL to implement the kind of lifecycle management that you would expect in a composition: the components would be deleted when the composite is. It could as well implement an ordinary association, if some business rules/contracts (e.g. UML post conditions) would require such a related deletion.

  • a ON DELETE SET NULL could help to implement a shared aggregation, if its smeantics would be defined as you mean: if the aggregate is deleted, its elements would not be deleted, and could therefore be shared. But it could as well implement any ordinary association, since the deletion of an associated instance would not trigger a deletion either and the constraint would allow to maintain a clean referential integrity.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • 1
    Where did the OP ask about databases? – qwerty_so Feb 22 '22 at 22:51
  • 2
    @qwerty_so I've completed: cascade and nullify are related to foreign key constraints. Moreover, the tags chosen by OP as "database" and "uml" ;-) – Christophe Feb 22 '22 at 23:05
  • 1
    @Christophe thank you for the patience. I think I made a mix between ERD and UML diagrams. I have seen ERD diagrams where it is indicated what happens in the cases of updating and deleting classes referenced by foreign keys. For example, "D:c" means cascading while "D:n" means nullify. The problem is that I keep the relational database so much in mind as I make the UML diagram, that in the end I think that the UML diagram is modeling a relational database instead of a software system. – BIOS-K Feb 23 '22 at 00:09
0

I agree, that composition means cascading delete, because according to UML the whole is responsible for the existence of the parts. A normal association means, you can delete any object without affecting any other objects that might have a link to it. UML doesn't define semantics for aggregation, so they will behave in the same way. But even if we take into account domain specific semantics for aggregation, I don't think there are examples where this is changed.

However, if you have an association with a multiplicity of 1 on one end, you cannot delete the object on this end, because the objects that have been linked to it would be invalid afterwards. This has nothing to do with composition or aggregation.

So, the remaining question is, how to express cascading delete if there is no whole-part relationship? Are there really examples where this happens? I don't see that Car - Driver, could not be in a whole-part relationship. Please bear in mind, that we are not talking about real cars or real people. We are talking about a software system that we want to represent knowledge about the real world for a specific purpose. And if the purpose is to issue boarding cards for cars and their drivers on a ferry, it makes perfect sense to view them as a composition.

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • In a fleet management system, you'll have many cars and many drivers. A car could be driven by more than one driver (e.g. successive drivers, or a team of drivers e.g. like when you rent a car with more than one potential driver, you'll notice that the rental company will register multiple drivers), and a driver could drive more than one car. In no way a whole-part relationship. In such a case, if you'd delete a driver you would not expect the car to be deleted, and this is where the nullify makes sense. – Christophe Feb 23 '22 at 23:10
  • Of course, the nullify requires that the fk is allowed to be null: the lower bound of multiplicity must hence be 0. If minimum would be 1, you'd not do anything on delete: the referential constraint would then make it impossible to delete the instance as long as it is used (i.e. referred to). – Christophe Feb 23 '22 at 23:24
  • @Christophe I think, this is exactly what I was trying to say. – Axel Scheithauer Feb 24 '22 at 14:01