2

I asked this question recently: Using Aggregation and Association

I accepted the answer, however I am confused by the answers response. The answerer talks about deleting database records. However, I am talking about the domain model, not the database.

Say I have a many to many relationship in the database like this:

CREATE TABLE Person (ID int, name varchar(100), dateofbirth datetime, primary key (ID))
CREATE TABLE Sport (ID int, description varchar(30), primary key (ID))
CREATE TABLE PersonPlaysSport (Person ID int references Person(ID), SportID int references Sport(ID), PRIMARY KEY (SportID, PersonID))

In the above database structure a person plays many sports.

Say I create two objects in the domain model i.e. one for Person and the other for Sport with a none to many relationship i.e. Person.Sports exists but Sports.People does not exist.

Can I describe the object relationship between Person and Sport in the object model as a composite in this scenario rather than an Association bearing in mind that a composite must:

1) Person owns Sport 2) Sport belongs to a single person 3) Persons lifeline controls sport lifeline

I am confused about point two. The database shows that a sport can be played by many people. However, the object model shows that a sport is played by no people (there is no sport collection in the Person class).

Can I represent a many to many relationship as a composite relationship in the object model?

  • 2
    This is not how association and composition work. Even though many books and articles give such examples. It depends on your requirements, business requirements and your design. You can make it association and that could be correct or wrong. You can make it composition and that could be correct or wrong. It all depends. If I do not want the sport to exist without a person, then I will make it composition. But if I do, then association. Within even the same application I could have it as association in one case but composition in another. Does that make sense? – CodingYoshi Nov 21 '17 at 3:34
  • @CodingYoshi, I think you have hit the nail on the head for me when you say: "Within even the same application I could have it as association in one case but composition in another". Are you saying that a relationship between two classes can be composition (strong) in one context and association (weak) in another? – w0051977 Nov 21 '17 at 15:49
  • 1
    Yes thats exactly what I am saying. It is NOT a rule set in stone that the relationship between a customer and an order is composition or association. It depends on your needs AND the design you have chosen to address those needs. Look at the .NET DataTable interface and see how it handles the creation of a DataRow. It's great design but it does not mean it will always have to be that way. What if you work for a tech company that only creates DataRows and your customers can take them and plug them into tables, how can you do composition without DataTable? You can't or better wouldn't. – CodingYoshi Nov 22 '17 at 3:42
2

I think you're confusing domain model entity & relationship cardinality with navigation by a technological implementation.

The domain model is an abstraction involving entities and potential relationships (cardinalities), which implies bidirectional navigation in the abstract, independent of any implementation (technology), whereas navigation within an implementation (technology) is a of mapping the abstract domain model to a specific relational model and/or to a specific object model.

In the relational model, navigation works bidirectionally by way of foreign keys & joins. It may perform poorly, and if so, we can introduce an index to help. An index changes only performance and neither capability nor syntax of how to navigate in either direction.

For object model technology, navigation generally requires references, e.g as collection, for n:1 or n:m, or as a field for 1:n.

The absence of a reference or collection in an entity of the object model precludes effective navigation at that (the object) level; however, this absence does not actually prevent a domain model relationship between entities in the abstract. To reiterate, missing navigational capabilities and/or constructors do not actually prevent the domain model from having relationships, it only really hampers the code attempting to create & navigate relationships at the object level.

Can I represent a many to many relationship as a composite relationship in the object model?

You can represent an n:m relationship as an association between two entities: each entity might typically have a navigable collection referring to the other.

If you omit either one or the other entity's collection, that will significantly hamper navigability (and certain constructions) but the abstract domain model having an n:m relationship between entities can still hold.

If you go nuts and eliminate both navigable collections, you can still represent the n:m relationship using a more direct mirror of the association table, perhaps using hash table(s).


If, say at the object level, we maintain navigable collections in both entities (for an n:m relationship), this actually represents duplicated data.

In the relational model, this data would be refactored into a relation table, and enjoy normalization, i.e. removing some duplication (also benefited by the help of bidirectional navigation).

In any representation, we should consider essential state vs. derived state. Derived state is duplicative, and has maintenance overhead (since without care it can go out of sync with the original/essential, though often considered worth that cost).

Of course, when there is state that is symmetrical, it is arbitrary which to consider essential vs. derived.

In terms of relational technology, maintaining derived state for performance is called de-normalization; in these and yet still other circles, it may be called caching.

2

The problem with giving you a clear answer here is that composition and association have a clearer definition than you've given sport.

If we take sport to mean something that lives independently of a single person then composition isn't right.

If we take sport to mean something exists only for that person than its fine.

If you find that unsatisfying you're not alone.

Really we need to think about what we're modeling here because just knowing what's happening in the database is not enough to know how to model this with objects. It's tempting to think there is always a 1 to 1 translation to make between DB and your object model but there is not. This problem actually has a name: the object relational impedance mismatch.

It's because of that mismatch that I can see several ways to build an object model of what's going on in your database. Which one I'd pick depends entirely on your business rules and far less than on what is going on in your database or indeed even if you have a database at all.

If all you want to do is to record the mapping between these you could do it with this:

PersonPlaysSport(Person person, Sport sport);

Done this way Person and Sport objects don't even know the other exists, which can be a good thing.

But before doing that consider if it really helps you. Would you better serve your business rules if Person took a List<Sport>?

It's really impossible for me to say from your question because you don't talk about your real needs. You just want a simple cookie cutter rule that says when the DB looks like this your objects should look like that. It's just not that simple. There are plenty of data binding libraries that people will sell you that pretend it is but that just ignores the problem.

Can I represent a many to many relationship as a composite relationship in the object model?

Strictly speaking, yes you can. But when you do so you're saying much more than the database tables you showed us were saying. You might even be saying something you shouldn't. To be composed of something means to be broken without it. It means you need it to work so that you will work because it's part of what you are. That's more than the DB tables were saying. It's more than they can say.

0

To me it looks like you try to fit a solution into a pattern that you do not fully understand and which is complex by nature.

What you should do is to step back a second and think about WHY you want this and not HOW you do it.

Don't fit something into a paradigm because you think it's a good choice, before you actually know WHAT your goal is.

Another thing, try to model, in pseudo-code how you would like the model-graph to look like.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.