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
I would think that is this better done with LDAP and defined roles and groups. Then use the J2EE security linked to the LDAP to control access. Remember that Entity beans represent data in the database. Unless each of these things are actual data then it should not be an entity bean. Jonathan Bricker Lilly Research Labs Java ATG Alex Paransky [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/02/01 05:06 PM Please respond to Orion-Interest To:Orion-Interest [EMAIL PROTECTED] cc: Subject:RE: Design strategy 1) It seemed to me that a class was merely a container of N groups. From your example, it seems that group (chemistry professor) was just a sub-group of a group called (Professor). In other words: Professor | +-- Chemistry Professor I was not aware of other fields in the Class, and this was the reason for the suggestion. Since you can still attach roles to the groups, from the example above Chemistry Professor could inherit the roles from the Professor Group 2) You can use standard many/many relationships for this. I have had limited success with this. -AP_ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale Sent: Monday, October 01, 2001 10:06 PM 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.
RE: Design strategy
Yes, I have noticed the same behavior in 2.0 CMP style beans. What I have
been doing is simply alerting orion-ejb-jar.xml, and changing one of the
tables into another one. So, instead of 2 tables, there is actually 1
table. I am not sure, if this is working correctly during transaction, in
other words, I think orion still keeps two separate relationships in memory
until a commit is done. So GroupBean.add(user), will not find group in
the user entity until a commit and update to the relational table. This
is somewhat frustrating and I am hoping will get fixed with the next release
of Orion (not clear when that will happen since we have not seen any updates
for over 9 months now!).
-AP_
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale
Sent: Wednesday, October 03, 2001 5:49 AM
To: Orion-Interest
Subject: 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
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.
RE: Design strategy
Owen You're design looks to handle the problem well. You can even adapt it slightly to get the database to help you with referential integrity. However, what you are doing is handling the inheritance manually. (This is not intended as a criticism.) EJB does not give you any support to do this. That is why you have to do it manually. You cannot create an Entity EJB that is abstract, and then create sub-classes for Class EJB, Group EJB and User EJB. Remember an EJB is a component. It has at least 2 interfaces (Home and Remote) and 1 class (Bean). Which one(s) do you sub-class? I had exactly the same problem with one of the most common sets of business entities to do with managing participants/parties. These are an abstract class called Party, and 2 concrete sub-classes called Person and Organisation. My solution was to implement an EJB for Party that handled Persons and Organisations. I had to manage the differences between the sub-classes manually. It also meant that my DAO were acting like AbstractFactories in that they could return Person or Organisation details, depending on what was actually retrieved from the db. Hopefully, a future version of the EJB spec will deal with inheritance. HTH James -Original Message- From: Owen Fellows [mailto:[EMAIL PROTECTED]] Sent: 02 October 2001 10:58 To: Orion-Interest 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.
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.
RE: Design strategy
george, this design issue should not be dependant on orion or any application server. orion can help becuase it supports ejb 1.1 and partially ejb 2.0. so there are a few options, you could write custom entites to manage the relationships, use ejb 1.1 or ejb 2.0. doing an ejb 2.0 implementation means you can model all the relationships in the ejb architecture, but be careful becaue i dont know how much of the ejb 2.0 specification orion supports. for ejb 2.0, doing the Class, Group and User relationships is pretty straight forward, all are standard one-to-many relationships. you may just need one entity bean for the Class entity and have the others as helper classes, orLocal ejbs, or have all three as entity beans. Class 1-* Group Group 1-* User To do the roles, is seems like you want 3 relationships. your diagram shows the one to many relationship Entity 1-* Role. It seems like you want the opposite Entity *-1 Role. Or if you want the entity to be able to map to severaldifferent roles, you would want Entity *--* Role. So each Entity (Class, Group and User) has the relationship defined. You would not have an abstract entity. So you would have 3 relationships like Class *---* Role Group *---* Role User *---* Role regards, simon [EMAIL PROTECTED] -Original Message-From: George Mardale [mailto:[EMAIL PROTECTED]]Sent: Monday, October 01, 2001 8:29 AMTo: Orion-InterestCc: [EMAIL PROTECTED]Subject: 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
1) It seemed to me that a class was merely a container of N groups. From your example, it seems that group (chemistry professor) was just a sub-group of a group called (Professor). In other words: Professor | +-- Chemistry Professor I was not aware of other fields in the Class, and this was the reason for the suggestion. Since you can still attach roles to the groups, from the example above Chemistry Professor could inherit the roles from the Professor Group 2) You can use standard many/many relationships for this. I have had limited success with this. -AP_ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale Sent: Monday, October 01, 2001 10:06 PM 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.
RE: Design strategy
I am not sure if your analysis is quite correct. The Group(1)-User(*) relationship is not quite correct, since User might want to be in two groups at the same time. For example, John can be in the group of Chemistry Professor, as well as Substitute Teacher. Your relationship implies that a user can ONLY be in 1 group. Similarly, your relationships to the Role imply that the same Role cannot be shared among various entities. In fact, most of the relationships are N-to-N type of relationships. A User CAN be in more than one Group, and the same Role CAN be applied to more than 1 User/Group. So here is my suggestion: 1. Dumpeither Class or Group 2.Assuming you dump Class, add a parent/children relationships to Group as inGroup(1)-Group(*), to indicate that one parent group can contain multiple children groups. 3. Add a Group(*)-Role(*) relationship to indicate that a group can have many roles and a single role can be in many groups 4. Add a User(*)-Role(*) relationship to indicate that a user can have multiple roles, and a role can accommodate many users 5. Finally, add a Group(*)-User(*) relationship to indicate that a user can be a part of many groups and a group can contain many users Your Group will contain a method called getRoles() as well as getAllRoles() which would scan up the Group tree and return a set of all the Roles assigned. Finally, your user would have a method called getRoles() and getAllRoles() to return just the roles assigned directly to the user, or all the roles that the user has access to through the assignment to a Group(s) or otherwise. You can also keep a side entity called UserRole which would be maintained as you change the Group/User/Role relationships dynamically. This will allow you to quickly answer the question isInRole(User, Role). This can be done with OrionServer. -AP_ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George MardaleSent: Monday, October 01, 2001 8:29 AMTo: Orion-InterestCc: [EMAIL PROTECTED]Subject: 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.
