В случае с API-интерфейсом аннотации @JoinTable в листинге 5.42 вы можете видеть два атрибута типа @JoinColumn: joinColumns и inverseJoinColumns. Они различаются владеющей и противоположной сторонами. Элемент joinColumns характеризует владеющую сторону (владельца связи) и в нашем примере ссылается на таблицу ORDER. Элемент inverseJoinColumns определяет противоположную сторону, то есть цель связи, и ссылается на ORDER_LINE.
При использовании сущности Order (листинг 5.44) вы можете добавить аннотации @OneToMany и @JoinTable для атрибута orderLines, переименовав таблицу соединения в JND_ORD_LINE (вместо ORDER_ORDER_LINE), а также два столбца внешнего ключа.
Сущность Order из листинга 5.44 будет отображена в таблицу соединения, описанную в листинге 5.45.
create table JND_ORD_LINE (
··ORDER_FK BIGINT not null,
··ORDER_LINE_FK BIGINT not null,
··primary key (ORDER_FK, ORDER_LINE_FK),
··foreign key (ORDER_LINE_FK) references ORDER_LINE(ID),
··foreign key (ORDER_FK) references ORDER(ID)
);
Правило по умолчанию для однонаправленной связи «один ко многим» — использование таблицы соединения, однако его очень легко (и целесообразно, если речь идет об унаследованных базах данных) изменить таким образом, чтобы применялись внешние ключи. Для сущности Order необходимо предусмотреть аннотацию @JoinColumn вместо @JoinTable, что позволит изменить код, как показано в листинге 5.46.
@Entity
public class Order {
··@Id @GeneratedValue
··private Long id;
··@Temporal(TemporalType.TIMESTAMP)
··private Date creationDate;
··@OneToMany(fetch = FetchType.EAGER)
··@JoinColumn(name = "order_fk")
··private List
··// Конструкторы, геттеры, сеттеры
}
Код сущности OrderLine (показанной в листинге 5.46) не изменится. Обратите внимание, что в листинге 5.46 аннотация @OneToMany переключает режим по умолчанию fetch (поменяв LAZY на EAGER). При использовании вами @JoinColumn стратегия внешнего ключа затем обеспечивает отображение однонаправленной связи. Внешний ключ переименовывается с помощью аннотации в ORDER_FK и располагается в целевой таблице (ORDER_LINE). В результате получается структура базы данных, показанная на рис. 5.17. Таблица соединения отсутствует, а ссылка между обеими таблицами осуществляется по внешнему ключу ORDER_FK.
Рис. 5.17. Столбец соединения между ORDER и ORDER_LINE
Двунаправленная связь «многие ко многим» имеет место, когда один объект-источник ссылается на много целей и когда цель ссылается на много источников. Например, CD-альбом создается несколькими артистами, а один артист принимает участие в создании нескольких CD-альбомов. В мире Java у каждой сущности будет коллекция целевых сущностей. В реляционном мире единственный способ отобразить связь «многие ко многим» — использовать таблицу соединения (столбец соединения не поможет). Кроме того, как вы уже видели ранее, при двунаправленной связи вам потребуется явным образом определить владельца (с помощью элемента mappedBy).
Если исходить из того, что сущность Artist является владельцем связи, то это будет означать, что противоположным владельцем (листинг 5.47) выступает сущность CD, которой необходимо, чтобы элемент mappedBy был использован в сочетании с ее аннотацией @ManyToMany. Элемент mappedBy сообщит поставщику постоянства о том, что appearsOnCDs — это имя соответствующего атрибута владеющей сущности.
@Entity
public class CD {
··@Id @GeneratedValue
··private Long id;
··private String title;
··private Float price;
··private String description;
··@ManyToMany(mappedBy = "appearsOnCDs")
··private List
··// Конструкторы, геттеры, сеттеры
}
Таким образом, если сущность Artist является владельцем связи, как показано в листинге 5.48, то она будет использоваться для настройки отображения таблицы соединения посредством аннотаций @JoinTable и @JoinColumn.