연관 매핑들은 올바른 것을 얻기가 종종 가장 어려운 것이다. 이 절에서 우리는 단방향 매핑들에서 시작하고, 그런 다음 양방향 경우들을 검토함으로써, 하나씩 표준적인 경우들을 상세히 논의할 것이다. 우리는 모든 예제들에서 Person과 Address를 사용할 것이다. 우리는 연관들을 중재하는 join 테이블로 매핑시킬 것인지 여부에 따라, 그리고 multiplicity(다중성)에 따라 연관들을 분류할 것이다. null 허용 가능한 foreign 키들은 전통적인 데이터 모델링에서 좋은 실례로 간주되지 않아서, 모든 우리의 예제들은 not null foreign 키들을 사용한다. 이것은 Hibernate에서 필수가 아니고, 당신이 null 허용 가능 컨스트레인트들을 드롭시킬 경우 매핑들은 모두 동작할 것이다. 단방향 many-to-one 연관은 가장 공통적인 종류의 단방향 연관이다. ]]> foreign 키에 대한 단방향 one-to-one 연관은 대개 아주 동일하다. 유일한 차이점은 컬럼 유일(unique) 컨스트레인트이다. ]]> 하나의 프라이머리 키에 대한 단방향 one-to-one 연관은 대개 특별한 id 생성기를 사용한다. (이 예제에서 연관의 방향이 역전되었음을 주목하라.) person ]]> 하나의 foreign 키에 대한 단방향 one-to-many 연관은 매우 색다른 경우이고, 실제로 권장되지 않는다. ]]> 우리는 이런 종류의 연관에 대해 하나의 join 테이블을 사용하는 것이 더 좋다고 생각한다. 하나의 join 테이블에 대한 단방향 one-to-many 연관이 보다 더 선호된다. unique="true"를 지정함으로써 우리는 many-to-many에서 one-to-many로 아중성(multiplicity)를 변경시켰음을 주목하라. ]]> 하나의 join 테이블에 대한 단방향 many-to-one 연관은 그 연관이 선택적일 때 매우 공통적이다. ]]> 하나의 join 테이블에 대한 단방향 one-to-one 연관은 극히 통상적이지 않지만 가능하다. ]]> 마지막으로, 우리는 단방향 many-to-many 연관을 갖는다. ]]> 양방향 many-to-one 연관은 가장 공통된 종류의 연관이다.(이것은 표준 부모/자식 관계이다. ) ]]> foreign에 대한 양방향 one-to-one 연관은 꽤 공통적이다. ]]> 하나의 프라이머리 키에 대한 양방향 one-to-one 연관은 특별한 id 생성기를 사용한다. person ]]> 하나의 join 테이블에 대한 양방향 one-to-many 연관. inverse="true"는 연관의 어느 쪽 끝이든 콜렉션 측으로 또는 join 측으로 갈 수 있다. ]]> 하나의 join 테이블에 대한 양방향 one-to-one 연관은 극히 통상적이지 않지만, 가능하다. ]]> 마지막으로, 우리는 하나의 양방향 many-to-many 연관을 갖는다. ]]>