Re: Multiple many-to-many with single-table inheritance
Re: Multiple many-to-many with single-table inheritance
- Subject: Re: Multiple many-to-many with single-table inheritance
- From: David Avendasora <email@hidden>
- Date: Sun, 4 Dec 2005 07:37:47 +0000
- Resent-date: Sun, 4 Dec 2005 13:20:37 +0000
- Resent-from: David Avendasora <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
I don't believe you need 3 many-to-many joins. There are three
different ways to handle this each with their own benefits/drawbacks.
1) Three to-one relationships:
- With the classes and attributes that you already have, create the
following to-one relationships
- Project.projectOwnerID -> Employee.employeeID
- Project.consulatantID -> Employee.employeeID
- Project.projectManagerID -> Employee.employeeID
The benefit of this method is that it is very easy to get the related
objects with getOwner() getProjectManager() etc. but this restricts
you to only one of each Owner, Consultant and Manager (which may be
valid for Owner and Manager, but almost certainly not for Consultant).
2) One Many-to-Many relationship:
- Remove the three Employee attributes from the Project class.
- Create an intermediate class of ProjectEmployee with the following
attributes
- projectEmployeeID (PK)
- projectID
- employeeID
- projectEmployeeTypeID
- Create type class of ProjectEmployeeType with the following attributes
- projectEmployeeTypeID
- typeName
- Create the following to-many relationships
- Project.projectID -> ProjectEmployee.projectID
- Employee.employeeID -> ProjectEmployee.employeeID
- ProjectEmployeeType.projectEmployeeTypeID ->
ProjectEmployee.projectEmployeeTypeID
- Create the following to-one relationships
- ProjectEmployee.projectID -> Project.projectID
- ProjectEmployee.employeeID -> Employee.employeeID
- ProjectEmployee.projectEmployeeTypeID ->
rojectEmployeeType.projectEmployeeTypeID
This gives you the most flexibility and the most "normalized"
database. You can have any number of Owners, Consultants and Managers
(may or may-not fit your business-logic) and you can easily add new
"types" of employees to the Project-Employee relationship by simply
creating new types. There's no need to change the data-structure or
the classes.
The drawback is that it makes the simple things like Project.getOwner
() method more involved because this method will not exist unless you
create it. You will have a getEmployees() method and you'll need to
modify it so you can pass the type you are requesting line
getEmployees("Owner") or something like that. Again, you can write
individual methods like getOwner() to hide this extra work, but it is
work you wouldn't need to do if you used to-one relationships.
3) One (or two) to-one relationships and one to-one relationship.
- If you KNOW you will only have one owner and/or one Manager, then
- keep those relationships as to-one as outlined above in option 1
- make the Consultants relationship to-many as outlined in option
2 (Eliminate the ProjectEmployeeType class and relationships)
This gives you easier to read and understand object and data models
and code, but is still quite inflexible.
I personally almost always use option 2 as it reduces the impact of
most common changes to the system that that WILL happen. When your
customer decides that you really need to have multiple Owners or that
each Project also has a Business Analyst or that Consultant is just
too generic. Option 2 makes all of these changes trivial where
options 1 and 3 force you to make major changes to the classes and
database. Up-front it's a little more work, but in the long run, it
will save you a LOT.
Hope this helps!
Dave
On Dec 4, 2005, at 5:00 AM, Drew Thoeni wrote:
I have a set of two objects:
Project
Employee
The Project has three attributes that relate to Employee:
projectOwnerID
consultantID
projectManagerID
I'd like to use single-table inheritance and have Employee with
children.
It is unclear to me how to create three many-to-many joins in
EOModeler between the two Objects (Project and Employee).
Is this possible? I can create the first one using "Join in Many-to-
Many", but adding the next fails as EOModeler has already created a
flattened relationship for "projects" and "employees."
The best idea I have is to rename the relationships from
"employees" to "owners", "consultants", and "projectManagers" and
rename the other side as "ownerProjects", "consultantProjects", and
"projectManagerProjects."
Is this the proper method?
Regards,
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden