macOS Question about "Core data" and Cardinality

[mdeh]

Hi all,
I am trying to get my head around this concept of cardinality, which on the face of it, seems quite intuitive.

Apple says:

Every relationship has a cardinality; the cardinality tells you how many destination objects can (potentially) resolve the relationship. If the destination object is a single object, then the relationship is called a to-one relationship. If there may be more than one object in the destination, then the relationship is called a to-many relationship.

In one of the tutorials on Cocoa for Scientists, the example uses a program to build an "application that allows you manage a personal database of molecules." The early object-graph developed looks like this.

http://images.macrumors.com/vb/images/attach/png.gif

Essentially, the Atom entity is related to the Element entity to-one, and the inverse is related to-many. Now intuitively, this makes sense. An atom can only be related to a single Element, but an Element could consist of any type of atom. But, when one boils it down, what **exactly** is being related? It would be correct, for example, to say that an instance of the Atom entity can only be related to a specific element entity, but the converse would also be true ie given a specific Element instance, one could only be related to a single atom instance. Clearly there is something more that I am missing.
Or...is it as simple as saying the analogy to the MVC would be something like this. In a to-one relationship, the ref in the Atom Class to the Element class would be an instance of the Element class, but in the Element class, the reference to the Atom class would be an **array** of Atom objects?
Anyway...if anyone has ever over thought this the way I usually do, and can clear my fuzzy thinking, that would be great.

Thanks in advance.

 

[lee1210]

An atom can only be classified as a single element. It can't be Aluminum and Neon at the same time. So if you have an atom, and it's an Aluminum atom, the only element it would relate to is Aluminum.

If you have the element Aluminum, in this universe one would presume that there is the possibility of more than one Aluminum atom. I know for a fact there is more than one, but even if there weren't there's at least the potential. There is nothing limiting the existence of aluminum to a single atom, there can be many.

So i think the point is that when you have an atom, it can map to one element. When you have an element, it can map to many atoms of that element.

-Lee

 

[mdeh]

So i think the point is that when you have an atom, it can map to one element. When you have an element, it can map to many atoms of that element.
-Lee

Hmmmm...good to hear from you again. Well, did not think of isotopes! But, I wonder if this is indeed what he was driving at. In my own mind, I visualized, as but one of the scenarios, that an element **could** ie have the potential of being any of a number of different types of atoms, ie the element **could** be H, HE, LI, Beb......etc etc, but an atom, as it relates to an element, could potentially **only** be an element. But then I analyze if a bit further and it fuzzes up again
And...when I try and extract it further, ie devoid of employees, atoms, books, artists and whatever else they are always using, it **really** falls apart

 

[lee1210]

I would expect that the relationship is from a concrete element not an "undefined" element. As such, it's mapping to atoms would be to any atom of that element. This might change if an atom undergoes fusion (er, two or more undergo fusion) or if it is split. But i see there being a distinct moment where there are two hydrogen atoms and another where there is one helium atom, so at first the element hydrogen maps to those two atoms (and many others), and after the fusion, helium now maps to the one resulting atom.

I am not a physicist, and I don't know that the site in question is trying to model complex atomic relationships and interactions. I could be mistaken, but I really believe that the idea is, given a concrete atom, it can only map to one element, and given a concrete element it can map to many atoms that are of that type.

This may make things worse rather than better, but if you had a Species class whose instances contained information about a specific animal species, and an Animal class whose instances represented a single, concrete animal, say your pet dog... the relationship would be the same. The Species instance representing Canis lupus familiaris would/could map to many dogs... say, Fluffy, Rover, and Sam. Going the other direction, Fluffy will only map to a single Species (in the absence of him being a dog-zebra chimera, but at that point he can probably breed with neither zebras or other dogs, so he's a new Zebog species Equus-canis lupus-quagga familiaris). That probably doesn't make things much clearer, but other relationships (familial for example) don't work quite the same way as the atom-element relationship.

-Lee

 

[mdeh]

I would expect that the relationship is from a concrete element not an "undefined" element. As such, it's mapping to atoms would be to any atom of that element. ......

Agreed...so far

I am not a physicist, and I don't know that the site in question is trying to model complex atomic relationships and interactions. I could be mistaken, but I really believe that the idea is, given a concrete atom, it can only map to one element, and given a concrete element it can map to many atoms that are of that type.

I am not a physicist either...so it's always dangerous, I guess, when two non-physicists are debating! But, let me play the devil's advocate here. Let's accept the premise that an atom can only map to one element, but the converse, ie that element **could** map to any of a gazillion atoms of that type. Could I not argue with equal validity that an atom could map to any of a number of the same types of elements?

........if you had a Species class whose instances contained information about a specific animal species, and an Animal class whose instances represented a single, concrete animal, say your pet dog... the relationship would be the same. The Species instance representing Canis lupus familiaris would/could map to many dogs... say, Fluffy, Rover, and Sam. Going the other direction, Fluffy will only map to a single Species (in the absence of him being a dog-zebra chimera, but at that point he can probably breed with neither zebras or other dogs, so he's a new Zebog species Equus-canis lupus-quagga familiaris). That probably doesn't make things much clearer, but other relationships (familial for example) don't work quite the same way as the atom-element relationship.-Lee

Lee, this last example was, what I was trying to convey, but clearly did not come across like this. But, I could have misunderstood you completely.

 

[lee1210]

I think that one would not really instantiate new elements. I suppose you could, but I would design it such that you can get *the* element Hydrogen, not *a* element Hydrogen. That's to say, there is only one Hydrogen Element instance, there can not be many. This could be dealt with by atomic number, etc. Basically the Element class would have a number of class methods that returned an Element * pointing to the one Element instance of that atomic number/type... subsequent calls would return the same object, as there is only one Element with atomic number 1, Hydrogen. There is not many "elements" with this atomic number and name. Just the one.

I'm not really sure how else to explain it, so I'll call it quits and let others jump in at this point... but NSColor is an example that might help. You can ask for magentaColor and get an object. You may be able to get many different objects that represent magentaColor, but they are the same. They represent the color magenta. A color or flavor or element or species isn't something you can have in your pocket or hold in your hand. They are ideas. An instance of an idea doesn't make "more" of that, there's just the one red, the one hydrogen, etc.

If this is still unclear, hopefully some others can toss their $.02 in.

-Lee

 

[mdeh]

Lee,
tks as always for your input. I plan to go ahead and do the example in Cocoa for Scientists, and will report back.

 

[hugo7]

Could I not argue with equal validity that an atom could map to any of a number of the same types of elements?

For a philosophical discussion, you absolutely could but for programming purposes, you introduce redundancy. A "many atom" to "many element" relationship buys you nothing since you could essentially use the two things interchangeably. In any design, the various entities (ie atom or element) should be unique and have meaningful relationships. This then forms a solid design starting point upon which to actually implement /code something. We don't want to get stuck in the realm of the hypothetical

Another way to look at this, although not necessarily the definitive answer, is that an atom is something concrete (a ball) whereas an element is just a type (a color).

"an atom is a specific type of element" (a red ball)
"many atoms can be of the same element" (five blue balls)

Now would you say "many identical blues map onto many balls" or simply state "the same blue maps onto many balls"?