• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Limiting number of assignments in a many-to-many relationship
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Limiting number of assignments in a many-to-many relationship


  • Subject: Re: Limiting number of assignments in a many-to-many relationship
  • From: Denis Stanton <email@hidden>
  • Date: Tue, 13 Jan 2004 19:08:34 +1300

Many persons can be assigned to an organisation
Many positions can be assigned to an organisation
Many email addresses can be assigned to an organisation

As I understand it, that would mean that I would have one-to-many relationships from person to organisation, from position to organisation and from email address to organisation.

You seem to be stating this back to front
If many persons can be assigned to an organisation then the person to organisation relationship is many to one,
alternatively you could say that the organisation to person relationship is one to many
These two statements are equivalent, but your statement above is the opposite


On Tuesday, January 13, 2004, at 12:47 PM, Steve Sharman wrote:

Many persons can be assigned to an organisation, a person can have only one organisation
Many positions can be assigned to an organisation, a position can have only one associated organisation


As I understood it, this would mean:

person <-->> organisation
position <-->> organisation

No. If you have many persons in one organisation then it is person <<-->organisation

Maybe this is not significant. Perhaps you knew what you meant, even if it was not exactly what you said

Having an organisation related to many persons, many positions and many something elses is not unusual for EO. In fact it's what Tiggers do best

with the associated foreign keys and relationships in place. For some reason I didn't think that this was possible (or the right way to do things) in EOF - I thought there could only be a single to-one relationship from a given entity. I don't know why I thought that.... something I've read and misunderstood probably.

I'm finding the wording confusing still. The use of to and from in "a single to-one relationship from a given entity" looses me. I think it is easier to imagine relationship "going from" than to describe it as "coming to"


I believe this is very simple to set up.
You have an organisation entity with a primary key called something like organisationID
Then in your person entity you define and integer also named organisationID
The same in your position entity.
Then you can go into the layout diagram mode (if forget the exact name) or EOM and control drag from the organisationID attribute of person to the organisationID attribute of organisation.
EO makes a to-one relationship --> from person to organisation
and a to-many relationship -->> from organistion back to person
Do the same for position and any others for which there are multiple items for one organisation


If you examine the class generated for organisation you will find it now has arrays names persons and positions.
EOM make these for you when you dragged the connection from person.organisationID to organisation.organisationID


Denis
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Limiting number of assignments in a many-to-many relationship (From: Steve Sharman <email@hidden>)

  • Prev by Date: WO or PHP?
  • Next by Date: WOTaskD not starting under 5.2.2/JDK 1.4.1 on Win2K
  • Previous by thread: Re: Limiting number of assignments in a many-to-many relationship
  • Next by thread: Re: Limiting number of assignments in a many-to-many relationship
  • Index(es):
    • Date
    • Thread