There are two side in a relationship : a source and a target. If you declare the relationship in only one of them, it's unidirectonal. If you declare it in both sides, it's bidirectional.
Here, the relation between employees and department is only declared on the employee side, thus it is unidirectional. Department does not reference Employee. If Department was looking like the following, then the relation would be bidirectional :
hi thanks for your reply.i know what is uniand bidirectional relationship. actually my doubt is that
for example both seller and item has reference to each other.Like that why cant the bid and bidder have the same but it is declared as only unidirectional.
we can say that one bidder places zero to many bids and also we can refer many bids are placed by one bidder which is bidirectional.but in the book only unidirection is mentioned and for seller and item they have given one seller sells many item and many item is sold by one seller.
hy cant the bid and bidder have the same but it is declared as only unidirectional.
I'll have to look at the book tonight But I guess it's a design decision. Of course, you can make it bidirectional, nothing prevents you from doing it. The example in the book just chooses to make it unidirectional (for educational reason ?). They decided that this time we didn't need to use the relation the other way around.
I don't have the book currently but it may be a design decision or maybe just to showcase an example of unidirectional relationship.
However it is very important to understand that unidirectional and bidirectional relationships are only present in the framework level and not at the DB level where only one type of relationship exists and that is undirectional (by foreign key).
posted 10 years ago
hi i am referring to the page in the pdf document.that is it is in chapter 7-7.1.2