Изучаем Java EE 7 - [81]
Если задействуется стратегия «таблица на класс» (или «таблица на конкретный класс»), то каждая сущность отображается в свою специально отведенную для этого таблицу, как при использовании стратегии «соединенный подкласс». Отличие состоит в том, что все атрибуты корневой сущности также будут отображены в столбцы таблицы дочерней сущности. С позиции базы данных эта стратегия денормализует модель и приводит к тому, что все атрибуты корневой сущности переопределяются в таблицах всех листовых сущностей, которые наследуют от нее. При стратегии «таблица на конкретный класс» нет совместно используемой таблицы, совместно используемых столбцов и столбца дискриминатора. Единственное требование состоит в том, что все таблицы должны совместно пользоваться общим первичным ключом — одинаковым для всех таблиц в иерархии.
Для отображения нашего примера с применением этой стратегии потребуется указать TABLE_PER_CLASS в аннотации @Inheritance (листинг 5.61) корневой сущности (Item).
>@Entity
>@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
>public class Item {
>··@Id @GeneratedValue
>··protected Long id;
>··protected String title;
>··protected Float price;
>··protected String description;
>··// Конструкторы, геттеры, сеттеры
>}
На рис. 5.26 показаны таблицы ITEM, BOOK и CD. Как вы можете видеть, в BOOK и CD имеются дубликаты столбцов ID, TITLE, PRICE и DESCRIPTION таблицы ITEM. Обратите внимание, что показанные таблицы не связаны.
Рис. 5.26. Наличие дубликатов столбцов таблицы ITEM в таблицах BOOK и CD
Разумеется, помните, что каждая таблица может быть переопределена, если снабдить каждую сущность аннотацией @Table.
Стратегия «таблица на конкретный класс» хорошо работает при выполнении запросов к экземплярам одной сущности, поскольку ее применение схоже с использованием стратегии «одна таблица на класс»: запрос ограничивается одной таблицей. Недостаток этой стратегии заключается в том, что она делает полиморфные запросы в иерархии классов более затратными, чем другие стратегии (например, поиск всех элементов, включая CD-альбомы и книги). При применении этой стратегии запросы ко всем таблицам подклассов должны выполняться с использованием операции UNION, которая оказывается затратной, если охватывается большой объем данных. Поддержка этой стратегии в JPA 2.1 все еще необязательна.
При использовании стратегии «таблица на конкретный класс» столбцы таблицы корневого класса дублируются в листовых таблицах. Они будут иметь одинаковые имена. Но что, если применять унаследованную базу данных, а столбцы будут обладать другими именами? JPA задействует аннотацию @AttributeOverride для переопределения отображения одного столбца и @AttributeOverrides, если речь идет о переопределении нескольких.
Чтобы переименовать столбцы ID, TITLE и DESCRIPTION в таблицах BOOK и CD, код сущности Item не потребуется изменять, однако придется задействовать аннотацию @AttributeOverride для сущностей Book (листинг 5.62) и CD (листинг 5.63).
>@Entity
>@AttributeOverrides({
>··@AttributeOverride(name = "id",
>·····················column = @Column(name = "book_id")),
>··@AttributeOverride(name = "title",
>·····················column = @Column(name = "book_title")),
>··@AttributeOverride(name = "description",
>·····················column = @Column(name = "book_description"))
>})
>public class Book extends Item {
>··private String isbn;
>··private String publisher;
>··private Integer nbOfPage;
>··private Boolean illustrations;
>··// Конструкторы, геттеры, сеттеры
>}
>@Entity
>@AttributeOverrides({
>··@AttributeOverride(name = "id",
>·····················column = @Column(name = "cd_id")),
>··@AttributeOverride(name = "title",
>·····················column = @Column(name = "cd_title")),
>··@AttributeOverride(name = "description",
>·····················column = @Column(name = "cd_description"))
>})
>public class CD extends Item {
>··private String musicCompany;
>··private Integer numberOfCDs;
>··private Float totalDuration;
>··private String genre;
>··// Конструкторы, геттеры, сеттеры
>}
Поскольку требуется переопределить несколько атрибутов, вам необходимо использовать аннотацию @AttributeOverrides, которая принимает массив аннотаций @AttributeOverride. После этого каждая аннотация указывает на атрибут сущности Item и переопределяет отображение столбца с помощью аннотации @Column. Таким образом, name = "title" ссылается на атрибут title сущности Item, а @Column(name = "cd_title") информирует поставщика постоянства о том, что title надлежит отобразить в столбец CD_TITLE. Результат показан на рис. 5.27.
Рис. 5.27. Таблицы BOOK и CD переопределяют столбцы таблицы ITEM
Ранее в разделе «Встраиваемые объекты» этой главы вы видели, что встраиваемый объект может совместно использоваться несколькими сущностями (Address был встроен в Customer и Order). Поскольку встраиваемые объекты — это внутренняя часть владеющей сущности, в таблице каждой сущности также будут иметься дубликаты столбцов, связанных с этими объектами. Кроме того, @AttributeOverrides можно применять, если вам необходимо переопределить встраиваемые столбцы.
