Hello Daniel,
What I said about those 2 tables, was strictly Orion-related. You are right,
in designing relational databases, a n-m relationship will be normalized by
introducing 1 (one) table and two 1-n relationships between the existing 2
tables (Group, User) and the new one (let's say GroupUser). Thus, we will
avoid redundancy.
In Orion, as far as I know, if I use something like this:
public class GroupBean ....
{
...
List users;
...
}
public class UserBean...
{
...
List groups;
....
}
to simulate a *-* relationship, Orion will create, by OR mapping, a table
for my first 1-* relationship Group->User (let's say the table is named
Group_users) and another table for my other 1-* relationship User->Group
(let's say the table is named Users_group). Of course, these 2 tables
(Group_users and Users_group) are identical, but I think Orion will not know
that these two 1-n relationships represent in fact one n-m relationship.
Please be advised that his is only my supposition about Orion. I don't know
if I'm right about this one but I'll be glad if someone can clarify this
issue for me. I was trying to find out for some days, how Orion handles *-*
relationships, but I wasn't lucky to find something useful.
best regards,
George.
----- Original Message -----
From: "Daniel Lopez" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, October 02, 2001 5:04 PM
Subject: Re: Design strategy
> Hi George,
>
> I don't know about EJB, as we don't use them, but having an extra table to
> represent an n-m relationship is a well stablished technique when
designing
> relational databases. AFAIK there's no other way to do that while
providing
> db-enforced consistency and avoiding redundancy. You represent a logical
n-m
> relationship, you create a new table that implements two real 1-n
relationships,
> thus creating one extra table. I don't see where you get two extra tables
per
> relationship from.
> regards,
> D.
>
> George Mardale wrote:
>
> > Hello Owen,
> >
> > Thank you for your kind response. Yesterday, while waiting for a
response on
> > the Orion mailing list, we thought of a design somehow close to yours.
We
> > thought that using 3 different tables (ClassRoles, GroupRoles,
UserRoles)
> > was a good ideea.
> >
> > But today, we came up with a solution that we thought would benefit of
> > Orion's powerful features. Thanks to Alex Paransky who helped us a lot,
we
> > tried to redesign the system, using OR mapping. So, we designed
something
> > like this:
> >
> > public class GroupBean implements EntityBean
> > {
> > ...
> > List users; //1..* relationship with UserBean
> > }
> >
> > public class UserBean implements EntityBean
> > {
> > ....
> > List groups; //1..* relationship with GroupBean
> > }
> >
> > Practically, we broke every *..* relationship (in this case Group(*) -
> > User(*)) into two 1..* relationships. And so on, for every relationship
that
> > we have:
> > Class(1) - Group(*)
> > User(*) - Role(*)
> > Group(*) - Role(*)
> > Class(*) - Role(*)
> >
> > As far as I know, Orion will create an additional table in the database
that
> > will store the relationship. For example, for users attribute in
GroupBean,
> > it will create a new table Group_users, besides the existing Group and
User
> > tables. Practically, for every *-* relationship will have 2 more tables
in
> > the database. Is that correct?
> >
> > What I want to know is if this design is correct. Are there any
drawbacks
> > that would make this system work unproperly (may be some OR mapping
> > problems)?
> >
> > Tkanks,
> > George.
> >
> > ----- Original Message -----
> > From: "Owen Fellows" <[EMAIL PROTECTED]>
> > To: "Orion-Interest" <[EMAIL PROTECTED]>
> > Sent: Tuesday, October 02, 2001 10:58 AM
> > Subject: RE: Design strategy
> >
> > > Hello,
> > >
> > > We have done a similar thing were we don't know the type of class
assign
> > the
> > > role except at runtime.
> > >
> > > The solution we used was to have an Object Type table (contain Class,
> > Group,
> > > User).
> > > Then created a interface which was Roleable (i.e. this class can have
a
> > role
> > > assigned).
> > > In the database you can store each assignment in a different table
> > > (ClassRoles, GroupRoles, UserRoles),
> > > or have a generic table that stores Roleable_id, Role_id and
> > Object_type_id.
> > >
> > > This does have drawbacks e.g. the Database does not have enforced
> > > consistence as the Roleable_id is not a foreign key on any one table.
It
> > > may also be slower to retrieve the Roles for a particular (Class,
Group,
> > > User) as you will have to lookup it object type and then its roles.
(You
> > > could always cache object types as there will not be that many).
> > >
> > > I'm sure you can implement a Bean with the above functionality (we
haven't
> > > used beans for this so I can help there).
> > >
> > > Hope this is of some help.
> > >
> > > Owen
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of George
Mardale
> > > Sent: 02 October 2001 06:06
> > > To: Orion-Interest
> > > Subject: RE: Design strategy
> > >
> > >
> > > Hello Alex,
> > >
> > > Thank you for your prompt response. Your suggestions are excellent.
> > >
> > > You're right, the analysis is not correct. I tried to reduce the
problem
> > to
> > > a
> > > simple example. To avoid complexity, I just limited the relationships
to
> > > 1..*.
> > > Maybe the example is not the best, but I only wanted to know if I
could
> > > model
> > > the "Abstract being" bean in Orion.
> > >
> > > There are still 2 issues we are unclear about:
> > > 1. what are the advantages of dumping entity Class? (Class has
specific
> > > fields
> > > that Group does not have)
> > > 2. could you please detail the best way to implement a *-*
relationship
> > in
> > > Orion?
> > >
> > > Thanks,
> > > George.
> > >
> > >
>
>
