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

Discussion in 'iOS Programming' started by wschutz, Jul 30, 2010.

  1. wschutz macrumors 6502

    Jun 5, 2007
    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 :)
  2. seepel macrumors 6502


    Dec 22, 2009
    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.
  3. Luke Redpath macrumors 6502a

    Nov 9, 2007
    Colchester, UK
    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.
  4. wschutz thread starter macrumors 6502

    Jun 5, 2007
    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!
  5. dejo Moderator


    Staff Member

    Sep 2, 2004
    The Centennial State
    Many-to-many relationships are typically modeled with a third entity. Pretty common in relational database design.

Share This Page