2013-11-13 1 views
2

Если у нас есть таблица сказать EMP_CONTACTTYPE, который, как показано нижеПроектирование JPA Entity объектов для отображения onToMany на той же сущности

EMP EMPNAME CONTACTTYPE CONTACT 
1  W  1   EMAIL 
2  X  1   EMAIL 
3  Y  2   PHONE 
4  Z  2   PHONE 

Если мы хотим, чтобы отобразить детали, как

EMAIL PHONE 
W  Y 
X  z 

Как мы должны разработать объект объекта как его сопоставление с той же таблицей «EMP_CONTACTTYPE».

Я создал два Entity объекта, один для контактов и один для Emp, как показано ниже, и получил onetomany отображения на Контакт Entity

Ниже Контактная Entity

@Entity 
@Table(name = "EMP_CONTACTTYPE") 
public class CONTACT 
{ 
private String CONTACT_TYPE; 
private String CONTACT; 

@OneToMany(fetch = FetchType.EAGER) 
@JoinTable(name = "EMP_CONTACTTYPE", joinColumns = { xxxxxx })  
private List<EMP> EMP; 
} 

и ниже ЕМР Entity

@Entity 
@Table(name = "EMP_CONTACTTYPE") 
public class EMP 
{ 
private String EMPLOYEE_NAME; 
private String EMPLOYEE_KEY; 
} 

Ожидаемый результат как для типа контактного объекта (1 и по электронной почте) Нам нужны два объекта Employee (W и X). Не уверен, является ли соединение решением для этого, или я не понимаю, как добавить к нему соединение. Любое предложение при разработке этого сценария.

+0

Имо, это не идеальная база данных. Это не так нормализовано, как может быть, и поэтому я бы сказал, что ему не хватает гибкости. Таблица EMP_CONTACTTYPE содержит данные, которые не являются полностью независимыми: у emoloyee может быть более одного набора контактных данных, каждый из которых имеет различный тип. Нормализованный дизайн разделил бы их на части и установил связь между этими двумя таблицами. Кроме того, поля CONTACT и CONTACTTYPE представляют собой дублирование одной и той же информации, поскольку поле CONTACT может быть получено из поля CONTACTTYPE. Он должен быть опущен из базы данных. – scottb

+0

@scottb Я согласился .. Его плохой дизайн. Разделение таблицы и определение отношения - правильное решение .. но у меня есть аналогичное требование, и БД уже определена долго назад, поэтому не сможет изменить дизайн базы данных. Как действовать в этом случае – Suraj

ответ

0

Вы можете объединить два класса Entity в один класс Entity или использовать две таблицы.

Предпочтительно, однако, вы разделили бы это на две таблицы и создали бы соответствующую взаимосвязь между двумя таблицами. Текущая схема не является оптимальной.

В любом случае, учитывая ситуацию и исходя из вашего комментария, поскольку у вас есть одна таблица, содержащая все эти данные, вы можете расширить класс EMP из класса CONTACT и создать столбец дискриминатора. При таком подходе вы найдете следующие полезные аннотации классов:

например.

@Inheritance(strategy = InheritanceType.JOINED) 
@DiscriminatorColumn(name = "columnname", discriminatorType = DiscriminatorType.INTEGER) 
@DiscriminatorValue(value = "value") 

Вы должны изучить эти аннотации и выбрать подходящую стратегию и т. Д. Это должно привести вас к правильному пути.

Если вы используете дискриминаторы с Hibernate, у вас также есть возможность указать формулу например.

<discriminator formula="case when CLASS_TYPE in ('a', 'b', 'c') then 0 else 1 end"  type="integer"/> 
+0

Но база данных уже разработана, и если она не может быть изменена, как действовать. Создание единого объекта, как обеспечить связь между Employee и ContactType.Это должно быть onetomany (для одного Contactype многие сотрудники) – Suraj

+0

Я пытался использовать вышеупомянутый подход, но я беспокоюсь о значении дискриминатора. Как добавить значение дискриминатора в сущности, может быть много значений. Что я сделал, так я создал столбец дискриминатора contactType, но мы не знаем, что в этих столбцах может быть много значений. – Suraj

+0

Если существует фиксированный набор значений дискриминатора, вы можете создать класс для каждого – cmd

Смежные вопросы