Hi Sylvain.
[snip]
>class Workstation { class OperatingSystem {
>int wPK int osPK
>String name String osName
>OperatingSystem os int version
>..... .....
>} }
>
>
>Relationnal tables are like:
>
>Workstation OperatingSystem
>----------- ---------------
>wPK: integer osPK: integer
>name: varchar osName: varchar
>osFK: integer verion: integer
>
>
>I create a osFK foreign key in the relationnal table
>Workstation to have the relationship between these 2 tables.
>This is, I think, a proper way to do this, right?
Yes.
>OK, now my questions about this example and OJB:
>
>1) [OJB question] do you need to create an osFK attribute in
>Workstation class?
Yes.
>2)[design question] what do you think if I put a wFK in the
>operatingSystem table instead of the osFK in Workstation
>table? Does it work with OJB?
Well, it might do, but it would not reflect the situation you describing.
>From what you said earlier, there is a one to many relationship (1:N)
between OperatingSystem and Workstation i.e. One OperationSystem has many
Workstations, but one WorkStation has only one OperatingSystem.
Putting a wFK on the OS/Table would give you many duplicated entries on the
OS table.
If you are trying to model One Workstation can have many OperatingSystems,
and many OperatingSystems can have many WorkStations, you are really
modelling a Many to Many relationship e.g. M:N.
OJB can handle these automagically, but I've never tried that myself (we
tend to model the intemediary table in our object model, as we often need to
store additional attributes about the relationship)
For more on M:N relationships, look at the Tutorial3.html document.
HTH a little,
Charles.
>
>Thank you
>Regards
>Sylvain
>
>
>-----Message d'origine-----
>De: Wulf Wechsung [mailto:[EMAIL PROTECTED]]
>Date: mercredi, 11. d�cembre 2002 19:53
>�: OJB Users List
>Objet: AW: Newbie question: associations
>
>
>Hi Sylvain,
>
>> For OJB, to do an association between Person and Address you
>need a foreign key attribute in your database. Normally you
>> should put a foreign key in the relationnal table Person
>(which contains an addressID). But you can also put a foreign
>key > in the table Address (which contains an personID)
>
>Those solutions are not really the same .. if you put the
>(fk)personid into the address table, it means that each
>address can only belong to one person and that each person can
>have multiple addresses.
>The otherway around means that an address may be associated
>with multiple people put that one person can only have one.
>
>Its a matter of design really. Usually you'd go with the
>personid in the address table since thats mostly the case in
>real life (where people have multiple addresses but *usually*
>an address has no more than one inhabitant), strictly speaking
>that'd be wrong though, the db-design-proper way to do this
>would be to create an association table to map people to
>addresses with maybe different phone numbers attached to
>address+person (like phone at home, phone at work, cell etc).
>For more information on database design, google up
>'normalisation +db' or 'database +modelling', that should get
>you started ...
>
>You need to map every primary key attribute in the database,
>I'd say (I am not so sure about that, though) ...
>
>And yes, with OJB you should be able to implement every
>*proper* database design where tables are normalized and the
>model is tailored to 'the real world'.
>
>Greetings,
>Wulf
>
>
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
