ORM. Расширенные темы 1

Embedded объекты Embedded объект – это объект, который не имеет собственной identity, а зависит от другой сущности В табличном представлении сама сущность и ее embedded сущность представляют одну строку таблицы. Физически не разделены Embedded сущности нужны, когда логически данные представляют собой отношение, а не просто коллекцию атрибутов, но БД хранит их физически в одной записи, по той или иной причине 2

Пример. Embedded объекты 3

Embedded объекты Embedded сущность помечается Embeddable сущность может содержать Embeddable сущность не может содержать мэпинги отношений Embedded сущность определяется в целевой сущности с При работе с целевой сущностью, провайдер опрашивает поля embedded сущности так, как будто эти поля определены на целевой сущности Необходимо рассмотреть возможность переопределения embedded сущности в обычную сущность, если модель данных допускает модификацию 4

Пример. Embedded объекты 5

Совместное использование Embedded объектов Возможна ситуация, когда две или более сущностей используют одинаковый embedded объект Так же возможна ситуация логически эквивалентных embedded объектов, но соответствующие им колонки таблиц физически имеют разные названия 6

Совместное использование Embedded объектов Можно использовать чтобы переопределить поле(я) embedded сущности При совместном использовании embedded сущности (класса) будет создано соответствующее количество экземпляров этого класса 7

Пример. Совместное использование Embedded объектов 8

Составной первичный ключ Первичный ключ таблицы БД использует несколько колонок. Распространено в legacy БД Необходимо создать дополнительный primary key класс Primary key класс должен: Быть public и имплементировать Serializable корректно переопределить методы equals() и hashCode() Иметь конструктор без параметров 9

Составной первичный ключ. Id класс Одним из видов primary key класса является Id класс Пример. Составной первичный ключ. Id класс (example_09-01) Primary key класс должен содержать атрибуты, совпадающие (по имени и типу) с primary key атрибутами целевой сущности Primary key класс может не иметь setterов. Провайдер установит поля один раз через reflection Primary key класс является удобной абстракцией ключа: 10

Составной первичный ключ. Embedded Id класс В качестве primary key класса может выступать embedded класс В этом случае embedded класс в целевой сущности аннотируется с Пример. Составной первичный ключ. Embedded Id класс (example_09-02) В запросах можно указывать путь, переходящий на поля embedded id класса, используя идентификатор id: 11

Read-only мэпинги JPA позволяет установить insertable и updatable свойства на индивидуальные поля состояния и поля отношений Можно установить значение false для insertable и/или updatable, в предположении, что данные уже существуют в БД Поля являются writable в памяти. Они не будут записаны в БД при flush сущности 12

Пример. Read-only мэпинги 13

Опциональность Можно указать провайдеру на опциональноть полей или single-valued ассоциаций Они могут быть null в БД На них не будет наложен not null constraint при генерации схемы Элемент optional может быть @OneToOne По умолчанию optional имеет значение true. Можно указать false 14

Пример. Опциональность 15

Отношения. Расширенные темы В случае, когда объектная модель может диктовать схему БД, сложные мэпинги не понадобятся В случае, когда БД уже существует и ее схему менять нельзя, необходимо иметь возможность не «стандартного» мэпинга 16

Составные join колонки В случае наличия compound ключа, может возникнуть возможность ссылки на него служит для хранения нескольких join колонок Таблица EMPLOYEE с compound ключом, ссылающимся на себя 17

Пример. Составные join колонки 18

Идентификаторы, которые включают отношение Возможно иметь compound ключ, который включает отношение. Этим подразумевается, что объект не может существовать без другого, являющегося частью идентификатора Используем primary key ссылается на колонку, уже являющуюся частью первичного ключа Пример. Идентификаторы, которые включают отношение (example_09-03) 19

Мэпинг состояния отношения (Relationship state) В примере дату начала работы сотрудника над проектом нельзя хранить ни в employee, ни в project, так как имеем отношение many-to-many В БД все просто: 20

Мэпинг состояния отношения (Relationship state) В Java состояние определяется как обычный мэпинг Объект состояния будет иметь Many-to-one мэпинг на целевые сущности (проект и работник) Первичный ключ объекта состояния будет compound, состоящий из двух отношений на целевые сущности Пример. Mapping Relationship state (example_09-04) 21

Несколько таблиц До сих пор мы рассматривали мэпинги, когда сущность мэпилась на один ряд одной таблицы! Это не всегда так в legacy БД, где логически связанные данные могут размещаться в разных рядах разных таблиц (по разным причинам) Таблица, для которой соответствующая сущность, называется primary table Таблица(ы), которой соответствуют связанные сущности, называется secondary table(s) 22

Несколько таблиц Сущность Когда часть данных primary сущности лежит в secondary сущности, необходимо указать эту secondary сущность в элементе table Для связывания primary таблицы и secondary табли ц, в служит Поддержка для связывания secondary таблиц ограничивается объединением первичного и вторичного ключей 23

Пример. Несколько таблиц 24

Пример. Несколько таблиц 25

Обзорный пример. Несколько таблиц. 26

Наследование Очень часто при ОО дизайне наследование используется неправильно – лишь для того, чтобы повторно использовать несколько методов О особой осторожностью необходимо использовать отношения наследования при O-R мэпинге 27

Пример. Наследование 28

Mapped супер класс JPA позволяет указывать mapped супер класс – класс не являющийся сущностью относительно него нельзя выполнять запросы он не может быть target сущностью Mapped супер класс может быть абстрактным или конкретным. Рекомендуется делать его абстрактным Mapped супер класс определяет часть состояния, которое недоступно непосредственно, но доступно сущностям, являющимся подклассами Mapped супер класс 29

Пример. Mapped супер класс 30

Transient классы в иерархии Класс в иерархии, не являющийся ни сущностью, ни mapped супер классом называется transient классом Состояние transient класса будет доступно подклассу (сущности или mapped супер классу), но это состояние не будет частью persistent состояния Transient класс удобно иметь для хранения временного состояния, промежуточных вычислений и т.п. 31

Пример. Transient классы в иерархии 32

Абстрактные и конкретные класс Сущность, mapped супер класс и transient класс могут быть абстрактными или конкретными Best practice делать mapped супер класс и transient абстрактными Делать абстрактной сущность может быть разумно, в случае, если данная сущность явно не используется в приложении, а используются ее подклассы Можно успешно выполнять JPQL запросы для абстрактной сущности – результатом будет набор сущностей, представляющих подклассы 33

Модели наследования JPA поддерживает 3 модели наследования Когда существует иерархия, она обязана иметь корневую сущность Корневая сущность аннотируется с помощью в качестве атрибута которой указывается тип модели наследования 34

Стратегия Single-Table Наиболее распространенная и быстрая схема Набор полей всех подклассов хранится в одной строке одной таблицы В строке содержатся параметры, значимые в контексте одного подкласса, и бессмысленные в контексте другого Это означает, что некоторые колонки строки будут незаполненными Первичный ключ указывается в корневой сущности и наследуется подклассами Стратегия Single-Table является стратегией по умолчанию и определяется с 35

Стратегия Single-Table. Discriminator Column Специальная колонка, не участвующая в мэпинге, служащая для разделения иерархии, называется discriminator column Обозначается с указанием имени discriminator колонки. По умолчанию имя DTYPE Элемент discriminatorType определяет тип колонки: String (по умолчанию) Integer Char 36

Стратегия Single-Table. Discriminator Value Каждый ряд таблицы должен иметь значение, в discriminator колонке, называемое discriminator value или индикатор класса Соответствующее значение должно быть указано на классе в иерархии, с По умолчанию в качестве discriminator value используется имя сущности Discriminator value может указываться только на конкретных сущностях 37

Пример. Стратегия Single-Table. Скриншот

Пример. Стратегия Single-Table. 39

Joined стратегия С точки зрения OO дизайна, разумно использовать отдельную таблицу для каждого класса в иерархии Хорошо нормализованная БД и хорошо декомпозированная ОО модель подходят под эту парадигму, но необходимо объединять таблицы. Такая стратегия называется Joined Strategy Однако, возможна потеря производительности Для связывания secondary таблиц используется foreign ключ, являющийся первичным ключом primary таблицы 40

Joined стратегия Необходимо явно указать Discriminator колонка по-прежнему необходима 41

Пример. Joined стратегия С 194 скриншот 42

Стратегия одна таблица на одну сущность Такая модель данных как правило будет означать дублирование данных и не нормализованную БД Данная стратегия потребуется в будущих релизах JPA, в данном релизе малопригодна Пример. Стратегия одна таблица на одну сущность (example 09-01) 43