iOS Core Data equivalent for attributes in many-to-many relationships

[wschutz]

I'm trying to set up a Core Data model for an iPhone application (instead of using SQLite which was my first idea...), and I am having a hard time modelling the equivalent of something pretty common in standard entity-relation models.

When modelling a many-to-many relationship between two entities in Core Data I understand that each entity must have a relationship to the other (as a to-many relationship) with the inverse parameter set to the relationship on the other entity (and the destination of the relationship set to the other entity).
This part is ok and mechanical, but what I don't know how to model is attributes for these kind of relationships when the designer considers there are.

In entity-relation models, many-to-many relationships are modelled as a third entity whose primary key is the primary keys of each entity of the couple entities involved. And many times, this many-to-many relationship can have more attributes (besides the primary keys as foreign keys).

For instance, if I have the following, where bold is the name of the entity, and what's inside of the parenthesis are attributes, and those attributes underlined are primary keys:

• Order(id, customer_id, date, confirmation, number)
• Product(id, name, price, description)
• OrderProduct(order_id, product_id, quantity)

What I want to model in Core Data is that attribute quantity which is linked to each product of every order (an assertion would be that the minimum should be one).
order_id and product_id would be a relationship on each entity, product and order respectively with the parameters set like I described previously, but then... I don't know how I can model the quantity because it doesn't belong to an order neither a product as it belongs to the join result of both entities...

Any ideas? Thanks from a newbie in Core Data development

 

[seepel]

As far as I know this isn't doable in Core Data, it makes the linking table automatically. Have you considered simply making the OrderProduct it's own entity? If you do this, I believe the table you get will be what you describe.

 

[Luke Redpath]

You should definitely look at making OrderProduct a separate entity. If you analyse it some more, the name OrderProduct is actually masking a hidden domain concept, namely LineItem.

So an order has many line items and a line item belongs to an order and has one product and a quantity. It may even make sense to denormalize the product details into the LineItem entity and drop the LineItem/Product link depending on your requirements; it may be perfectly valid for a product to be deleted or discontinued in the future although you would still want to preserve the product data to maintain the integrity of the Order object.

Of course, that's not the only approach you could take. You could maintain the link between LineItem and Product and enforce a rule that Products cannot be deleted if they have any associated line items. You could then add a discontinued flag to Product to indicate when a Product is no longer for sale and should not be displayed.

 

[wschutz]

You're both right A few hours after I posted this thread I re-read Apple's documentation about many-to-may relationships, and they have an example which is not exactly the one I presented, in fact it is a bit more complex, but the documentation suggests a third entity as well when extra information for a many-to-many relationship is required. I guess I missed as I didn't fully read about it since it didn't look like the "standard" problem.

I thought that Core Data had something to do this automatically, since I found quite cool that designer/developer doesn't have to take care of a third entity for many-to-many relationships (when there are no extra attributes of course), but it seems it doesn't, though if it had, it would probably be a very obscure manner, and a third entity is a much better approach.

Thanks for your suggestions, specially to Luke The example I used it is not exactly the one I'm implementing (in fact the application I'm developing it's about bus transportation...), but you have shed some ideas of interest. Thanks!

 

[dejo]

Many-to-many relationships are typically modeled with a third entity. Pretty common in relational database design.