IS-A relationships in core data

  • Hi,

    This is definitely a Core Data newbie question, but exactly how do
    you handle IS-A relationships in Core Data.

    I assume you designate the super entity as "Parent". But what about
    attribute settings? Do you have the option to denormalize the data
    (copy some attributes from the sub-entity into the super-entity)? (I
    will eventually only be searching on one file, and only afterwards
    getting related records from the other files.)

    I'll give a concrete example.

    Lets say I have a MasterList created from three separate lists,
    ListA, ListB, and ListC. Let's say that the MasterList has certain
    properties (last name, first name) in common that will also be found
    in data from the individual lists. However, the structure of the
    three individual lists may otherwise be different.

    I will be getting the data for the individual lists from flat files
    that I parse.

    How do I set up the data model? I tried having identical names for
    last name and first name, and got an error when I compiled. Then I
    thought of having a MasterList recNum attribute, and then placing
    that attribute in the individual lists (an approach recommended in
    some database books), but that also caused a problem.

    Since the basic tutorial describes HAS-A scenarios, I'm not getting
    very far with the type of model I want to set up.

    Thanks.

    Daniel
  • On Nov 15, 2007, at 10:23 PM, Daniel Child wrote:

    > how do you handle IS-A relationships in Core Data.
    > [...]
    > Lets say I have a MasterList created from three separate lists,
    > ListA, ListB, and ListC. Let's say that the MasterList has certain
    > properties (last name, first name) in common that will also be found
    > in data from the individual lists. However, the structure of the
    > three individual lists may otherwise be different.
    >
    It's not clear what you mean.  You seem to be describing a has-a
    relationship.
    If you want to define an inheritance hierarchy, use inheritance:

    <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
    /cdMOM.html
    >

    mmalc
  • OK, let me rename the tables:

    Words (a "master list")
    OldEnglishWords (one of the contributing lists)
    ModernEnglishWords (another contributing list)
    FrenchOriginWords (another contributing list)

    All three subsidiary lists are special types of Words, with their own
    separate fields (attributes). Unfortunately, the article you cite
    doesn't help much. Yes, of course you set the parent entity. But I'm
    asking about approaches to normalizing or denormalizing the data. Let
    me expand the example.

    Every Word has an orthographic realization ("spelling") and a
    pronunciation.
    WORD (spelling, pronunciation)

    Every FrenchOriginWord will have a frenchSpelling, which may be
    different from its English spelling. Thus,

    FRENCHORIGINWORD (spelling, pronunciation, frenchSpelling)

    Assuming that spelling can serve as the key field in both tables,
    then normally you simply copy the super-entity's key field into the
    sub-entity attributes lists and make it the key as well. (Apparently,
    you could do the reverse, but the DB design books recommends the
    former approach.)

    When I name the two fields the same thing, XCode says they conflict.
    Does that mean I have to rename the spelling key in FRENCHORIGINWORD?
    That is rather weird.

    Is Core Data using surrogate keys in the background? Does it give you
    an option to set surrogate keys?

    On Nov 16, 2007, at 11:01 AM, mmalc crawford wrote:

    >> how do you handle IS-A relationships in Core Data.
    >> [...]
    >> Lets say I have a MasterList created from three separate lists,
    >> ListA, ListB, and ListC. Let's say that the MasterList has certain
    >> properties (last name, first name) in common that will also be
    >> found in data from the individual lists. However, the structure of
    >> the three individual lists may otherwise be different.
    >>
    > It's not clear what you mean.  You seem to be describing a has-a
    > relationship.
    > If you want to define an inheritance hierarchy, use inheritance:
    >
    > <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
    > Articles/cdMOM.html>
  • Like subclasses, subentities inherent their parent entity's properties. If Word has a "spelling" attribute, its subentities have that as well, so you can't (and don't need to) give them another identical attribute.

    Cheers,
    Chuck

    ----- Original Message ----
    From: Daniel Child <wchild...>
    To: mmalc crawford <mmalc_lists...>
    Cc: cocoa-dev cocoa-dev <cocoa-dev...>
    Sent: Friday, November 16, 2007 11:06:22 AM
    Subject: Re: IS-A relationships in core data

    OK, let me rename the tables:

    Words (a "master list")
    OldEnglishWords (one of the contributing lists)
    ModernEnglishWords (another contributing list)
    FrenchOriginWords (another contributing list)

    All three subsidiary lists are special types of Words, with their own
    separate fields (attributes). Unfortunately, the article you cite
    doesn't help much. Yes, of course you set the parent entity. But I'm
    asking about approaches to normalizing or denormalizing the data. Let
    me expand the example.

    Every Word has an orthographic realization ("spelling") and a
    pronunciation.
    WORD (spelling, pronunciation)

    Every FrenchOriginWord will have a frenchSpelling, which may be
    different from its English spelling. Thus,

    FRENCHORIGINWORD (spelling, pronunciation, frenchSpelling)

    Assuming that spelling can serve as the key field in both tables,
    then normally you simply copy the super-entity's key field into the
    sub-entity attributes lists and make it the key as well. (Apparently,
    you could do the reverse, but the DB design books recommends the
    former approach.)

    When I name the two fields the same thing, XCode says they conflict.
    Does that mean I have to rename the spelling key in FRENCHORIGINWORD?
    That is rather weird.

    Is Core Data using surrogate keys in the background? Does it give you
    an option to set surrogate keys?

    On Nov 16, 2007, at 11:01 AM, mmalc crawford wrote:

    >> how do you handle IS-A relationships in Core Data.
    >> [...]
    >> Lets say I have a MasterList created from three separate lists,
    >> ListA, ListB, and ListC. Let's say that the MasterList has certain
    >> properties (last name, first name) in common that will also be
    >> found in data from the individual lists. However, the structure of
    >> the three individual lists may otherwise be different.
    >>
    > It's not clear what you mean.  You seem to be describing a has-a
    > relationship.
    > If you want to define an inheritance hierarchy, use inheritance:
    >
    > <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
    > Articles/cdMOM.html

          ____________________________________________________________________________________
    Be a better pen pal.
    Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/
  • On Nov 16, 2007, at 11:06 AM, Daniel Child wrote:

    > When I name the two fields the same thing
    >
    Why are you doing this?
    If OldEnglishWords inherits from Words, then it gets the keys from
    Words...

    mmalc
  • On Fri, November 16, 2007 11:06 am, Daniel Child wrote:
    >
    > Is Core Data using surrogate keys in the background? Does it give you
    > an option to set surrogate keys?
    >

    Yes, Core Data uses surrogate keys in the background. No, we don't give
    you the option to set them.

    +Melissa
  • So in the Core Data model, are they treated as two separate tables?

    My SQL is rusty, but I believe you would be defining a field in each
    table linking the two. That was why I had the impulse to do this. The
    classic example from my DB book had:

    CLIENT (clientID, name, amtDue)
    PARTNERSHIP_CLIENT (clientID, taxID, managingPartnerName, etc...)
    CORPORATE_CLIENT (clientID, contactPerson, phone, etc.)

    The point is that you add the key of the supertype (clientID) into
    the subtype table, or vice versa.

    The fact that Core Data does NOT do this makes it hard to know
    exactly how things are handled. Apparently, the relations are handled
    using surrogate keys (as stated in the response by Melissa Turner at
    Apple), but there is no option of whether or not to set them. It is
    not clear to me how to define my key fields. Supposing, for instance,
    I want two fields together to be the key field, is there any way to
    do that?

    A related question is whether Core Data handles object-relational
    scenarios. The examples I've seen show you how to set basic attribute
    types (string, integer, etc.), and how to set 1-N or N-M relations.
    But what if you want one of those attributes to be an object of some
    kind. Do you choose NSData as the attribute type?

    So one source of my confusion stems from the fact that Core Data can
    store data in SQLite format, but does not really work like SQL at all.

    Another question is that, while Core Data can store data in XML
    format, can it really handle complex hierarchical structures like
    those in dictionaries, where there may be any number of parts of
    speech indicators, meanings, associated explanations or sample
    sentences, etc?

    If Core Data can do this, then I should go beyond the initial
    tutorials and try to master it. If not, I should devote my time to
    something else that will. I would love to be able to use it, however,
    as doing things from scratch would be very tedious.

    Thanks.

    On Nov 16, 2007, at 2:29 PM, mmalc crawford wrote:

    >
    > On Nov 16, 2007, at 11:06 AM, Daniel Child wrote:
    >
    >> When I name the two fields the same thing
    >>
    > Why are you doing this?
    > If OldEnglishWords inherits from Words, then it gets the keys from
    > Words...
  • On Nov 20, 2007, at 9:50 AM, Daniel Child wrote:

    > So in the Core Data model, are they treated as two separate tables?
    >
    There is no guarantee that there are tables.  SQLite is only one of
    the possible stores.
    If you're trying to make Core Data act like a database, you're doing
    the wrong thing -- see <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
    /cdBasics.html
    >.

    It's not clear what you're trying to achieve.

    mmalc
  • On Nov 20, 2007, at 9:50 AM, Daniel Child wrote:

    > A related question is whether Core Data handles object-relational
    > scenarios. The examples I've seen show you how to set basic
    > attribute types (string, integer, etc.), and how to set 1-N or N-M
    > relations. But what if you want one of those attributes to be an
    > object of some kind. Do you choose NSData as the attribute type?
    >
    This is covered in the Core Data Programming Guide.

    mmalc
  • On Nov 20, 2007, at 9:50 AM, Daniel Child wrote:

    > The fact that Core Data does NOT do this makes it hard to know
    > exactly how things are handled. Apparently, the relations are
    > handled using surrogate keys (as stated in the response by Melissa
    > Turner at Apple), but there is no option of whether or not to set
    > them. It is not clear to me how to define my key fields. Supposing,
    > for instance, I want two fields together to be the key field, is
    > there any way to do that?
    >
    Core Data defines its own primary keys.  You cannot specify a primary
    key (simple or compound) of your own.

    mmalc
  • On Nov 20, 2007, at 9:50 AM, Daniel Child wrote:

    > Another question is that, while Core Data can store data in XML
    > format, can it really handle complex hierarchical structures like
    > those in dictionaries, where there may be any number of parts of
    > speech indicators, meanings, associated explanations or sample
    > sentences, etc?
    >
    If you can express the data in terms of a schema and an object graph,
    then there should be no reason why it cannot be represented using Core
    Data.

    > So one source of my confusion stems from the fact that Core Data can
    > store data in SQLite format, but does not really work like SQL at all.
    >
    Indeed, to reiterate part of the article I mentioned in the first
    reply (hmm, which should have had an opening sentence, "I'll address
    various points in separate replies to keep them focused."):

    "If you're trying to make Core Data act like a database, you're doing
    the wrong thing -- see <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
    /cdBasics.html
    >."

    "Core Data provides an infrastructure for object graph management and
    persistence."  In some respects it does act like a RDBMS, in many
    others it emphatically does not -- for example, you do fetch data
    using a query term, but you don't have access to primary keys, join
    tables used to establish many-to-many relationships are hidden from you.

    mmalc
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today