Re: 3 way Many to many
Re: 3 way Many to many
- Subject: Re: 3 way Many to many
- From: Jevon Hills <email@hidden>
- Date: Mon, 27 Jan 2003 09:38:49 -0700
Oops Typo.
You CAN'T circumvent the model.....
On Monday, January 27, 2003, at 09:18 AM, Jevon Hills wrote:
Here is my attempt to send an ascii ER model of what we're thinking of.
+==========+
+console +
+----------------- +
-------+consoleID +
| +==========+
|
|
|
+========================+ |
+ConsolePersonPermission + | +========= +
+------------------------------------------+ | +person +
+consoleID +---------- | +-----------------+
+personID +----------------- +personID +
+permissionID +---------- | +==========+
+========================+ |
| +=============+
| +permission +
| +----------------------+
|-------+permissionID +
+=============+
This way you can circumvent the model. You must link
People to Consoles to Permissions
all at once.
Jevon
On Friday, January 24, 2003, at 03:06 PM, Art Isbell wrote:
On Friday, January 24, 2003, at 06:23 AM, Jevon Hills wrote:
We now wish to set up a 3 way (Many to Many to Many) relation ship.
For Example a Person has a set of permissions on a console. We want
to
model a person having different sets of permissions for different
consoles.
[demime 0.98b removed an attachment of type multipart/appledouble]
In the old way of doing this I would just acquire the 3 id's I needed
and create a new row. How do I set this up in EOModeler so that I
can
create/use the technology to my advantage.
Because your attachment was stripped, I'm not certain what you're
trying to model. In any event, this really isn't a WO issue per se
but an entity-relationship modeling issue that would apply to any
database design environment. Maybe someone in this forum can
recommend a good ER modeling book.
So the first thing you need to do is design the model. Then
EOModeler should be able to implement the model. If one of the
entities involved in a many-to-many relationship is also involved in
another many-to-many relationship, then you should be able to create
that relationship in EOModeler in exactly the same way as before.
Person <<-->> Console <<->> Permission
But maybe what you really want is:
Person <-->> PersonConsole <<--> Console
^
|
-->> Permission
In this case, the PersonConsole join entity represents a person's
access to a console with that access governed by one or more
permissions.
In general, if you need to create and access join entity objects
(e.g., when the join entity contains real data - i.e., has attributes
other than primary keys), you must delete the flattened relationships
between Person and Console in the above example and make the
underlying relationships class properties so you can access the join
entity via these relationships. This will require that you
programmatically manage these underlying relationships just as you do
any other relationships, so EOF will no longer be able to maintain
the many-to-many relationships automatically.
Also, to avoid excessive fetching, you'll need to remove
relationships not traversed by your app from being class properties.
This step normally occurs during the performance tuning phase of
development.
Art
http://homepage.mac.com/aisbell/
_______________________________________________
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.
Jevon K. Hills
Intern - Zymeta Media Promotion Systems
Jevon K. Hills
Intern - Zymeta Media Promotion Systems
_______________________________________________
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.