OR mapping (1/* relationship between 2 entity beans)
Hello everyone,
I have an OR mapping that involves 2 entity beans, named Group and User,
like in the following example:
public class GroupBean implements EntityBean
{
...
List users;
public addUser(User user)
{
users.add(user);
}
}
So, I have an 1/* relationship.
What I want to know is what modifications do I have to made to
orion-ejb-jar.xml to reflect this OR mapping? On the orionsupport site,
there are 2 example for advanced OR mapping, one involving a relationship
between 2 entity bean, but in an one/one relationship (one entity bean has
as an attribute other entity bean, not a list of them), and one involving a
relationship between an entity bean and a regular JavaBean (not an entity
bean). I tried to combine those two to solve my situation, but it didn't
worked out.
If you are kind enough to give me an example, I will greatly appreciated.
Thanks for listening,
George.
Re: Design strategy
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
Re: Design strategy
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.
Design strategy
Hi everybody, During our last application design, I have encountered the following issue and I don't know ifOrion can handled it in a specific manner: I have a hierarchy of users that consists of 3 levels: Class, Group, User. A class can contain one or more groups, a group can contain one or more users. For instance, an instance of Class can be "professor", an instance of Group can be "chemistry professor", and an instance of User can be "John" (John is a chemistry professor). We have 1..* relationship for each of the 3 levels. Of course, theseare entity beans. Furthermore, we have another entity bean, called Role. The ideea is that every User canhave a Role in an application (for instance, John can be a SystemAdmin inan application), but also, a Group or a Class canhave one or moreRoles (instead of assigning a Role to every User in a Group or a Class, we assign the Role to the whole Group or Class,saving a lot of time this way, thus all the User in the respective Group or Classwill have that Role). For all the Roles, we need to keepthe id of the person(s) to whomthe Role was assigned.But only at run-time Ican find out the type of the component in the user hierarchy (either Class, Group, or User), to which the rolehas beenassigned.In other words, an attribute in class Role has to store a value that is sometimes an instance of Class, sometimes an instance of Group and sometimes an instance of User. Analyzing this issue, we came along with this diagram: 1 * Abstract being -- Role | inherits -- | | | | | | Class Group User 1--- * 1- * How can we achieve this in Orion? Is it possible? Thank you for your time, best regards, George.
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.
Orion as a service on Windows NT 4
Hello everybody! I want to install Orion as a service on Windows NT 4. Can anyone give me an idea how to do it? Thanks in advance, George.
