Яка "власна сторона" в картографуванні ORM?

Що саме означає сторона володіння ? Яке пояснення з деякими прикладами картографування ( один до багатьох, один до одного, багато до одного )?

Наступний текст - уривок із опису документації @OneToOne в Java EE 6. Ви можете побачити сторону концепції, що є в ній.

Визначає однозначну асоціацію до іншої сутності, яка має множинність один на один. Зазвичай не потрібно чітко вказувати асоційований цільовий об'єкт, оскільки він, як правило, може бути виведений з типу об'єкта, на який посилається. Якщо взаємозв'язок є двонаправленим, сторона , яка не володіє, повинна використовувати елемент mappedBy анотації OneToOne для визначення поля відносин або властивості сторони, що володіє.

Чому потрібне поняття власної сторони:

Ідея власного боку двонаправленого відношення походить від того, що в реляційних базах даних немає двонаправлених відносин, як у випадку з об'єктами. У базах даних ми маємо лише однонаправлені відносини - зовнішні ключі.

У чому причина назви "володіння стороною"?

Сторона, що має відношення, відстежується в сплячому режимі, - це сторона відносини, якій належить зовнішній ключ у базі даних.

Яка проблема, яку вирішує поняття володіння стороною?

Візьмемо приклад двох сутностей, відображених без декларування власного боку:

@Entity
@Table(name="PERSONS")
public class Person {
    @OneToMany
    private List<IdDocument>  idDocuments;
}

@Entity
@Table(name="ID_DOCUMENTS")
public class IdDocument {
    @ManyToOne
    private Person person;
}

З точки зору ОО, це відображення визначає не одне двонаправлене відношення, а два окремі однонаправлені відносини.

Відображення створило б не тільки таблиці PERSONSта ID_DOCUMENTS, але й створило б третю таблицю асоціацій PERSONS_ID_DOCUMENTS:

CREATE TABLE PERSONS_ID_DOCUMENTS
(
  persons_id bigint NOT NULL,
  id_documents_id bigint NOT NULL,
  CONSTRAINT fk_persons FOREIGN KEY (persons_id) REFERENCES persons (id),
  CONSTRAINT fk_docs FOREIGN KEY (id_documents_id) REFERENCES id_documents (id),
  CONSTRAINT pk UNIQUE (id_documents_id)
)

Зверніть увагу , що первинний ключ pkна ID_DOCUMENTSтільки. У цьому випадку Hibernate відстежує обидві сторони відношення незалежно: Якщо ви додаєте документ у відношення Person.idDocuments, він вставляє запис у таблицю асоціацій PERSON_ID_DOCUMENTS.

З іншого боку, якщо ми зателефонуємо idDocument.setPerson(person), ми змінимо іноземний ключ person_id на столі ID_DOCUMENTS. Hibernate створює два однонаправлені (зовнішні ключові) відносини в базі даних, щоб реалізувати одне двостороннє відношення об'єкта.

Як поняття володіння стороною вирішує проблему:

Багато разів то , що ми хочемо тільки зовнішній ключ на столі в ID_DOCUMENTSстороні PERSONSі додаткова таблиця асоціації.

Щоб вирішити це, нам потрібно налаштувати Hibernate, щоб припинити відстежувати модифікації відношення Person.idDocuments. Спящий режим повинен відслідковувати лише іншу сторону відносин IdDocument.person, і для цього ми додаємо mappedBy :

@OneToMany(mappedBy="person")
private List<IdDocument>  idDocuments;

Що означає відображеноBy?

Це означає що - щось на кшталт: «модифікації на цій стороні відносин вже Підключення До іншій стороні відносин IdDocument.person, тому немає необхідності відстежувати його тут окремо в додатковій таблиці.»

Чи є якісь ГОТЧИ, наслідки?

Використання mappedBy , якщо ми тільки називаємо person.getDocuments().add(document), зовнішній ключ в ID_DOCUMENTSбуде НЕ бути пов'язані з новим документом, оскільки це не володіє / гусенична боку відносини!

Щоб зв’язати документ з новою особою, вам потрібно чітко зателефонувати document.setPerson(person), оскільки це є власною стороною відносин.

Використовуючи mappedBy , розробник несе обов'язок знати, що є власником, і оновлювати правильну сторону співвідношення, щоб викликати збереження нового відношення в базі даних.

Ви можете уявити, що сторона, що володіє, - це сутність, яка має посилання на іншу. У своєму уривку у вас стосунки один на один. Оскільки це симетричне відношення, то в кінцевому підсумку ви будете мати те, що якщо об’єкт A знаходиться у відношенні до об'єкта B, то і навпаки вірно.

Це означає, що збереження в об'єкті A посилання на об'єкт B і збереження в об'єкті B посилання на об'єкт A буде зайвим: саме тому ви вибираєте, який об'єкт "володіє" іншим, на який має посилання.

Коли у вас є взаємозв'язок "один на багато", об'єкти, пов'язані з частиною "багато", будуть стороною власності, інакше вам доведеться зберігати багато посилань від одного об'єкта до безлічі. Щоб уникнути цього, кожен об'єкт другого класу матиме вказівник на єдиний, на який вони посилаються (тому вони є власником).

Для відносин "багато-до-багатьох", оскільки вам все одно знадобиться окрема таблиця відображення, не буде жодної сторони.

На закінчення, власником є суб'єкт господарювання, який має посилання на іншу.