Heavily normalized 1:1 relationships

Question

We have a schema in which entries in one table are related to entries in another table, but several different ways, with each "different way" represented as a different relation table.
For example, if an employee has two different addresses, one for work, and one for home, the schema would have an "employee" table (with "emp_id" as its primary key), an "address" table (with "addr_id" as its key), and two relation tables: "work_address" and "home_address", each of which has an "emp_id" column that's a foreign key into "employee" and an "addr_id" column that's a foreign key into "address".
What I'm trying to do is set up a mapping that'll result in the Employee class having a "workAddress" member and a "homeAddress" member (with each being, e.g., a ValueHolder for an Address).
In the workbench, though, I can't seem to make the descriptor for the Employee class "jump over" the intermediate/relation table directly to the ultimate target. Instead, it looks like I'll have to have intermediate classes (e.g., "WorkAddress" and "HomeAddress"), which would require a second level of access to actually get the address.
One alternative, I think, would be to drop the relation tables and change the "employee" table to have a "work_addr_id" and "home_addr_id" columns (that would be foreign keys into "address"), but I'd prefer to use the schema as-is, and wonder if there's any way to specify using intermediate/relation tables without having them be part of the model.
Any info would be appreciated.
Thanks,
Brad McFarlane

Answer 1

Brad
With your database schema, in theory every employee could have many work addresses and many home addresses. Conversely, each address could be valid for several employees.
If your object model stipulates that each employee has one and only one home and work address, you would need to specify some kind of flattening or constraint on your database model. For example, you could create a view on your database tables
create view xxx as
select e.employeeId, min(homeAddress.addressId) as homeAddressId, min(workAddress.addressId)
from employees e
join homeAddress on e.employeeId = ha.employeeId
etc.
Or you could specify a unique constraint in the homeAddress and workAddress tables on employeeId, and then perhaps map the Employee class as a multitable mapping (advanced properties), with the primary key of the second table (employeeHomeAddresses) specified as employeeId (since it is unique). Then add a 1:1 mapping to the address object / table. The mapping idea may be incorrect - I have not used multitable functionality so far, but think it should work.
Hope this is of some value :)
Jamees