객체/관계형 매핑들은 대개 XML 문서 내에 정의된다. 매핑 문서는 가독성이 있고 수작업 편집이 가능하도록 설계되어 있다. 매핑 언어는 매핑들이 테이블 선언들이 아닌, 영속 클래스 선언들로 생성된다는 의미에서 자바 중심적이다. 심지어 많은 Hibernate 사용자들이 수작업으로 XML을 작성하고자 선택할지라도, XDoclet, Middlegen, 그리고 AndroMDA를 포함하는, 매핑 문서를 생성시키는 많은 도구들이 존재한다는 점을 노트하라. 예제 매핑으로 시작하자: ]]> 우리는 이제 매핑 문서의 내용을 논의할 것이다. 우리는 Hibernate에 의해 실행 시에 사용되는 문서 요소들과 속성들 만을 설명할 것이다. 매핑 문서는 또한 스키마 내보내기 도구에 의해 내보내진 데이터베이스 스키마에 영향을 주는 어떤 특별한 옵션 속성들과 요소들을 포함한다. (예를 들어 not-null 속성.) 모든 XML 매핑들은 doctype이 보이게 선언해야 한다. 실제 DTD는 위의 URL에서, hibernate-x.x.x/src/org/hibernate 디렉토리 내에서 또는 hibernate3.jar 내에서 찾을 수 있다. Hibernate는 항상 첫 번째로 그것의 classpath 속에서 DTD를 찾게 될 것이다. 만일 당신이 인터넷 연결을 사용하는 DTD에 대한 룩업들을 겪게 될 경우, 당신의 classpath의 컨텐츠에 대해 당신의 DTD 선언을 체크하라. 이 요소는 몇 개의 선택적인 속성들을 갖는다. schema 속성과 catalog 속성은 이 매핑 내에서 참조된 테이블들이 명명된 schema 와/또는 catalog에 속한다는 점을 지정한다. 만일 지정될 경우, 테이블 이름들은 주어진 schema 이름과 catalog 이름에 의해 한정(수식)될 것이다. 누락될 경우, 테이블 이름들은 한정되지((수식어가 붙지) 않을 것이다. default-cascade 속성은 cascade 속성을 지정하지 않은 프로퍼티들과 콜렉션들에 대해 전제될 cascade 스타일이 무엇인지를 지정한다. auto-import 속성은 디폴트로 우리가 질의 언어 속에서 수식어가 붙지 않은(unqualified) 클래스 이름들을 사용하게 할 것이다. ]]> schema (옵션): 데이터베이스 스키마의 이름. catalog (옵션): 데이터베이스 카다록의 이름. default-cascade (옵션 - 디폴트는 none): 디폴트 cascade 스타일. default-access (옵션 - 디폴트는 property): Hibernate가 모든 프로퍼티들에 액세스하는데 사용하게 될 방도. PropertyAccessor에 대한 맞춤형 구현일 수 있다. default-lazy (옵션 - 디폴트는 true): class 및 collection 매핑들의 지정되지 않은 lazy 속성들에 대한 디폴트 값. auto-import (옵션 - 디폴트는 true): 우리가 질의 언어 내에 (이 매핑에서 클래스들에 대해) 수식어가 붙지 않은 클래스 이름들을 사용할 수 있는지를 지정한다. package (옵션): 매핑 문서 내에서 수식어가 붙지 않은 클래스 이름들에 대해 가정할 패키지 접두어를 지정한다. 만일 당신이 동일한 (수식어가 붙지 않은) 이름을 가진 두 개의 영속 클래스들을 갖고 있다면, 당신은 auto-import="false"를 설정해야 한다. 만일 당신이 두 개의 클래스들에 동일한 "imported" 이름을 할당하려고 시도할 경우에 Hibernate는 예외상황을 던질 것이다. 위에 보여진 것처럼 hibernate-mapping 요소는 몇몇 영속 <class> 매핑들을 내부에 포함하는 것을 허용해준다는 점을 노트하라. 하지만 한 개의 매핑 파일 속에 한 개의 영속 클래스(또는 한 개의 클래스 계층구조) 만을 매핑하고 영속 서브 클래스 뒤에 그것을 명명하는 것이 좋은 연습이다 (그리고 몇몇 도구들에 의해 기대된다). 예를 들면 Cat.hbm.xml, Dog.hbm.xml 또는 상속을 사용할 경우에는 Animal.hbm.xml. 당신은 class 요소를 사용하여 영속 클래스를 선언할 수도 있다: ]]> name (옵션): 영속 클래스(또는 인터페이스)의 전체 수식어가 붙은 Java 클래스 이름. 만일 이 속성이 누락될 경우, 매핑이 non-POJO 엔티티라고 가정된다. table (옵션 - 디폴트는 수식어가 붙지 않은 클래스명): 그것의 데이터베이스 테이블의 이름. discriminator-value (옵션 - 디폴트는 클래스 이름): 다형성(polymorphic) 특징에 사용되는, 개별 서브 클래스들를 구별짓는 값. 허용가능한 값들은null과 not null을 포함한다. mutable (옵션 - 디폴트는 true): 클래스들의 인스턴스들이 가변적인지를 (가변적이지 않은지를) 지정한다. schema (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 스키마 이름을 오버라이드 시킨다. catalog (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 카다록 이름을 오버라이드 시킨다. proxy (옵션): lazy initializing proxy들에 사용할 인터페이스를 지정한다. 당신은 클래스 그 자체의 이름을 지정할 수 도 있다. dynamic-update (옵션 - 디폴트는 false): UPDATE SQL이 실행 시에 생성되고 그들 컬럼들의 값들이 변경된 그들 컬럼들 만을 포함할 것인지를 지정한다. dynamic-insert (옵션 - 디폴트는 false): 생성될 INSERT이 실행 시에 생성되고 그들 컬럼들의 값이 null이 아닌 컬럼들 만을 포함할 것인지를 지정한다. select-before-update (옵션 - 디폴트는 false): 객체가 실제로 변경되는 것이 확실하지 않는 한, Hibernate가 SQL UPDATE를 결코 실행하지 않을 것임을 지정한다. 어떤 경우들에서(실제로 transient 객체가 update()를 사용하여 새로운 session에 연관되었을 때에만), 이것은 하나의 UPDATE가 실제로 필요한 경우인지 여부를 결정하기 위해 Hibernate는 특별한 SQL SELECT를 실행할 것임을 의미한다. polymorphism (옵션 - 디폴트는 implicit): implicit 질의 다형성이나 explicit 질의 다형성 중 어느 것이 사용될 것인지를 결정한다. where (옵션) 이 클래스의 객체들을 검색할 때 사용될 임의적인 SQL WHERE 조건을 지정한다 persister (옵션): 맞춤형 ClassPersister를 지정한다. batch-size (옵션 - 디폴트는 1) 식별자에 의해 이 클래스의 인스턴스들을 페치시키는 "배치 사이즈"를 지정한다. optimistic-lock (옵션 - 디폴트는 version): optimistic 잠금 방도를 결정한다. lazy (옵션): lazy="false"를 설정함으로써 Lazy fetching이 전체적으로 사용불가능하게 될 수 있다. entity-name(옵션, 디폴트는 클래스 이름): Hibernate3는 하나의 클래스가 (잠정적으로 다른 테이블들로) 여러번 매핑되는 것을 허용해주고, Java 레벨에서 Map 또는 XML에 의해 표현 되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티에 대한 명시적인 임의의 이름을 제공해야 한다. entity-name (옵션): Hibernate3는 하나의 클래스가 (잠정적으로 다른 테이블들로) 여러 번 매핑되는 것을 허용하며, 자바 레벨에서 Map들 또는 XML에 의해 표현되는 엔티티 매핑들을 허용한다. 이들 경우들에서, 당신은 그 엔티티들에 대한 명시적인 임의의 이름을 제공해야 한다. 추가 정보는 과 을 보라. check (옵션): 자동적인 스키마 생성을 위한 다중-행 check constraint를 생성시키는데 사용되는 SQL 표현식. rowid (옵션): Hibernate는 지원되는 데이터베이스들, 예를 들어 Oracle 상에서 이른바 ROWID들을 사용할 수 있고, Hibernate는 당신이 이 옵션을 rowid로 설정하는 경우에 빠른 업데이트를 위한 특별한 rowid 컬럼을 사용할 수 있다. ROWID는 구현 상세이고 저장된 튜플(tuple)의 물리적이니 위치를 표현한다. subselect (옵션): 불변의 읽기 전용 엔티티를 데이터베이스 subselect로 매핑시킨다. 당신이 기본 테이블 대신에 뷰를 갖고자 원할 경우에 유용하지만, 사용을 자제하라. 추가 정보는 아래를 보라. abstract (옵션): <union-subclass> 계층 구조들 내에서 abstract 슈퍼클래스들을 마크하는데 사용된다. 명명된 영속 클래스가 인터페이스가 되는 것은 완전히 수용가능하다. 그런 다음 당신은 <subclass> 요소를 사용하여 그 인터페이스에 대한 구현 클래스들을 선언할 것이다. 당신은 임의의 static inner 클래스를 영속화 시킬 수 있다. 당신은 표준 형식, 예를 들어 eg.Foo$Bar를 사용하여 클래스 이름을 지정해야 한다. 불변의 클래스, mutable="false"는 어플리케이션에 의해 업데이트되지 않을 것이거나 삭제되지 않을 것이다. 이것은 Hibernate로 하여금 어떤 마이너 퍼포먼스 최적화를 행하게끔 허용해준다. 선택적인 proxy 속성은 그 클래스의 영속 인스턴스들에 대한 lazy 초기화를 가능하게 해준다. Hibernate는 명명된 인터페이스를 구현하는 CGLIB 프락시들을 초기에 반환할 것이다. 실제 영속 객체는 프락시의 메소드가 호출될 때 로드될 것이다. 아래 "Lazy 초기화를 위한 프락시들"을 보라. Implicit 다형성은 클래스의 인스턴스들이 어떤 서브클래스나 구현된 인터페이스 또는 클래스를 명명하는 질의에 의해 반환될 것임을 의미하고 그 클래스의 어떤 서브클래스에 대한 인스턴스들이 그 클래스 자체를 명명하는 질의에 의해 반환될 것임을 의미한다. Explicit 다형성은 클래스 인스턴스들이 그 클래스를 명시적으로 명명하는 질의들에 의해서만 반환될 것임을 의미고 그 클래스를 명명하는 질의들이 이 <class> 선언 내부에서 <subclass> 또는 <joined-subclass>로 매핑된 서브 클래스들의 인스턴스들 만을 반환하게 될 것임을 의미한다. 대부분의 용도로, 디폴트인 polymorphism="implicit"가 적절하다.두 개의 다른 클래스들이 동일한 테이블로 매핑될 때 Explicit 다형성이 유용하다(이것은 테이블 컬럼들의 서브셋을 포함하는 "경량급" 클래스를 허용한다). persister 속성은 클래스에 사용되는 영속화 방도를 당신이 커스트마이징 할 수 있도록 해준다. 예를 들어 당신은 org.hibernate.persister.EntityPersister에 대한 당신 자신의 서브클래스를 지정할 수도 있거나 당신은 심지어 예를 들어 플랫 파일들이나 LDAP로의 직렬화,내장 프로시저 호출들을 통해 영속화를 구현하는 인터페이스 org.hibernate.persister.ClassPersister에 대한 완전히 새로운 구현을 제공할 수도 있다. (Hashtable로의 "영속성"에 관한) 간단한 예제는 org.hibernate.test.CustomPersister를 보라. dynamic-update 설정과 dynamic-insert 설정은 서브클래스들에 의해 상속되지 않고 따라서 또한 <subclass> 또는 <joined-subclass> 요소들 상에 지정될 수도 있음을 노트하라. 이들 설정들은 몇몇 경우들에서 퍼포먼스를 증가시키지만 다른 경우들에서는 퍼포먼스를 실제로 감소시킬 수도 있다. 적절하게 사용하라. select-before-update 사용은 대개 퍼포먼스를 감소시킬 것이다. 당신이 detached 인스턴스들의 그래프를 Session에 다시 첨부할 경우에 그것은 데이터베이스 업데이트 트리거가 불필요하게 호출되는 것을 방지하는데 매우 유용하다. dynamic-update를 사용가능하게 할 경우, 당신은 다음 optimistic 잠금 전략들을 선택하게 될 것이다: version은 version/timestamp 컬럼들을 체크한다 all은 모든 컬럼들을 체크한다 dirty는 몇몇 동시성 업데이트들을 허용하여, 변경된 컬럼들을 체크한다 none은 optimistic 잠금을 사용하지 않는다 우리는 당신이 Hibernate에서 optimistic 잠금을 위해 version/timestamp 컬럼들을 사용할 것을 매우 강력하게 권장한다. 이것은 퍼포먼스에 대해 최적의 방도이고 detached 인스턴스들에 대해 행해진 변경들을 정확하게 핸들링하는 유일한 방도이다(예를 들어 Session.merge()가 사용될 때). Hibernate 매핑의 경우에 베이스 테이블과 뷰 사이에 차이점이 존재하지 않는다. 왜냐하면 이것이 데이터베이스 레벨에서는 투명하다고 기대되기 때문이다(몇몇 DBMS는 뷰를 고유하게 지원하지 않고 특히 뷰 업데이트를 지원하지 않음을 노트하라). 때때로 당신이 뷰를 사용하고자 원하지만, (예를 들어 리거시 스키마로) 데이터베이스 속에 뷰를 생성시킬 수 없다. 이 경우에, 당신은 불변의 읽기 전용 엔티티를 주어진 SQL subselect 표현식으로 매핑시킬 수 있다: select item.name, max(bid.amount), count(*) from item join bid on bid.item_id = item.id group by item.name ... ]]> auto-flush가 정확하게 발생하도록 하고, 그리고 파생된 엔티티에 대한 질의들이 쓸효성 없는 데이터를 반환하지 않도록 함으로써, 이 엔티티와 동기화 될 테이블을 선언하라. <subselect>는 속성과 내포된 매핑 요소 양자로서 이용 가능하다. 매핑된 클래스들은 데이터베이스 테이블의 프라이머리 키 컬럼을 선언해야 한다. 대부분의 클래스들은 또한 인스턴스의 유일 식별자를 소유하는 자바빈즈-스타일 프로퍼티를 가질 것이다. <id> 요소는 그 프로퍼티로부터 프라이머리 키 컬럼으로의 매핑을 정의한다. node="element-name|@attribute-name|element/@attribute|." ]]> name (옵션): 식별자 프로퍼티의 이름. type (옵션): Hibernate 타입을 나타내는 이름. column (옵션 - 디폴트는 프로퍼티 이름): 프라이머리 키 컬럼의 이름. unsaved-value (옵션 - 디폴트는 "sensible" 값): 이전 세션에서 저장되었거나 로드되었던 detached(분리된) 인스턴스들로부터 그것을 구분지우도록, 인스턴스가 새로이 초기화되어 있음(저장되어 있지 않음)을 나타내는 식별자 프로퍼티 값. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. name 속성이 누락되면, 클래스는 식별자 프로퍼티를 갖지 않는다고 가정된다. unsaved-value 속성은 Hibernate3에서는 거의 필요하지 않다. composite 키들로서 리거시 데이터에 액세스하는 것을 허용해주는 대체적인 <composite-id> 선언이 존재한다. 우리는 그 밖의 어떤것에 대한 그것의 사용에 대해 강력하게 반대한다. 선택적인 <generator> 자식 요소는 영속 클래스의 인스턴스들에 대한 유일 식별자들을 생성시키는데 사용되는 자바 클래스를 명명한다. 만일 임의의 파라미터들이 생성기 인스턴스를 구성하거나 초기화 시키는데 필요할 경우, 그것들은 <param> 요소 를 사용하여 전달된다. uid_table next_hi_value_column ]]> 모든 생성기들은 org.hibernate.id.IdentifierGenerator 인터페이스를 구현한다. 이것은 매우 간단한 인터페이스이다; 몇몇 어플리케이션들은 그것들 자신의 특화된 구현들을 제공하도록 선택할 수 있다. 하지만 Hibernate는 미리 빈드된 구현들의 영역들을 제공한다. 빌드-인 생성기(generator)들에 대한 단축 이름들이 존재한다: increment 동일한 테이블 속으로 데이터를 입력하는 다른 프로세스가 없을 때에만 유일한 long, short 또는 int 타입의 식별자들을 생성시킨다. 클러스터 내에서는 사용하지 말라. identity DB2, MySQL, MS SQL Server, Sybase, HypersonicSQL에서 식별 컬럼들을 지원한다. 반환되는 식별자는 long, short 또는 int 타입이다. sequence DB2, PostgreSQL, Oracle, SAP DB, McKoi에서 시퀀스를 사용하거나 Interbase에서 생성기(generator)를 사용한다. 반환되는 식별자는 long, short 또는 int 타입이다. hilo 테이블과 컬럼(디폴트로 각각 hibernate_unique_key와 next_hi)이 hi 값들의 소스로서 주어지면, long, short 또는 int 타입의 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다. hi/lo 알고리즘은 특정 데이터베이스에 대해서만 유일한 식별자들을 생성시킨다. seqhilo 명명된 데이터베이스 시퀀스가 주어지면, long, short 또는 int 타입의 식별자들을 효과적으로 생성시키는데 hi/lo 알고리즘을 사용한다. uuid 네트웍 내에서 유일한(IP 주소가 사용된다) string 타입의 식별자들을 생성시키기 위해 128 비트 UUID 알고리즘을 사용한다. UUID는 길이가 32인 16진수들의 문자열로서 인코딩 된다. guid MS SQL Server와 MySQL 상에서 데이터베이스 생성 GUID 문자열을 사용한다. native 기본 데이터베이스의 가용성들에 의존하여 identity, sequence 또는 hilo를 찾아낸다. assigned 어플리케이션으로 하여금 save()가 호출되기 전에 식별자를 객체에 할당하도록 한다. <generator> 요소가 지정되지 않을 경우 이것이 디폴트 방도이다. select 어떤 유일 키에 의해 행을 select하고 프라이머리 키 값을 검색함으로써 데이터베이스 트리거에 의해 할당된 프라이머리 키를 검색한다. foreign 또 다른 연관된 객체의 식별자를 사용한다. 대개 <one-to-one> 프라이머리 키 연관관계와 함께 사용된다. hilo와 seqhilo 생성기들은 식별자 생성에 대한 마음에 드는 접근법인, hi/lo 알고리즘에 대한 두 개의 대체 구현들은 제공한다. 첫 번째 구현은 다음에 이용 가능한 "hi" 값을 수용하기 위한 "특별한" 데이터베이스 테이블을 필요로 한다. 두 번째는 (지원되는) Oracle 스타일의 시퀀스를 사용한다. hi_value next_value 100 ]]> hi_value 100 ]]> 불행히도 당신은 Hibernate에 당신 자신의 Connection을 제공할 때 hilo를 사용할 수 없다. Hibernate가 JTA의 도움을 받는 커넥션들을 얻기 위해 어플리케이션 서버 데이터소스를 사용할 때 당신은 hibernate.transaction.manager_lookup_class를 적절하게 구성해야 한다. UUID 는 다음을 포함한다: IP 주소, JVM의 시작 시간(정확히 1/4 초), 시스템 시간과 (JVM 내에서 유일한) counter 값. Java 코드로부터 MAC 주소 또는 메모리 주소를 얻는 것은 불가능하여서, 이것은 우리가 JNI를 사용하지 않고서 행할 수 있는 최상의 것이다. 식별 컬럼들을 지원하는 데이터베이스들(DB2, MySQL, Sybase, MS SQL)의 경우, 당신은 identity 키 생성을 사용할 수 있다. 시퀀스들을 지원하는 데이터베이스들(DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB)의 경우, 당신은 sequence 스타일 키 생성을 사용할 수도 있다. 이들 방도들 모두 새로운 객체를 insert하기 위해 두 개의 SQL 질의들을 필요로 한다. person_id_sequence ]]> ]]> 크로스 플랫폼 개발을 위해서, native 방도가 기준 데이터베이스들의 가용성들에 따라 identity, sequence, hilo 방도 중에서 선택될 것이다. (Hibernate로 하여금 식별자들을 생성시키도록 하는 것과는 반대로) 당신이 어플리케이션으로 하여금 식별자들을 할당하도록 원할 경우, 당신은 assigned 생성기를 사용할 수 있다. 이 특별한 생성기는 객체의 identifier 프로퍼티에 이미 할당된 식별자 값을 사용할 것이다. 이 생성기(generator)는 프라이머리 키가 대용(surrogate ) 키 대신에 natural 키일 때 사용된다. 당신이 <generator> 요소를 지정하지 않을 경우에 이것이 디폴트 특징이다 assigned 생성기(generator)를 선택하는 것은 , version 또는 timestamp 프로퍼티가 존재하지 않는 한 또는 당신이 Interceptor.isUnsaved()를 정의하지 않는 한, 하나의 인스턴스가 transient 또는 detached인지를 결정하기 위해 Hibernae로 하여금 데이터베이스에 접촉하도록 강제하는, unsaved-value="undefined"를 Hibernate에게 사용하도록 한다. 리거시 스키마에 대해서만(Hibernate는 트리거들을 가진 DDL을 생성시키지 않는다). socialSecurityNumber ]]> 위의 예제에서, natural 키로서 클래스에 의해 socialSecurityNumber로 명명된 유일 값을 가진 프로퍼티가 존재하고, 트리거에 의해 그 값이 생성되는 person_id로 명명된 대용키가 존재한다. node="element-name|." ...... ]]> composite 키를 가진 테이블의 경우, 당신은 클래스의 여러 프로퍼티들을 식별자 프로퍼티들로서 매핑할 수 있다. <composite-id> 요소는 자식 요소들로서 <key-property> 프로퍼티 매핑과 <key-many-to-one> 매핑들을 허용한다. ]]> 당신의 영속 클래스는 composite 식별자 동등성을 구현하기 위해서 equals()와 hashCode()를 오버라이드 시켜야 한다. 그것은 또한 Serializable을 구현해야 한다. 불행히도, composite 식별자들에 대한 이 접근법은 영속 객체가 그것 자신의 식별자라는 점을 의미한다. 객체 자신 외의 다른 "핸들"이 존재하지 않는다. 당신은 당신이 composite key로 연관된 영속 상태를 load() 할 수 있기 이전에 영속 클래스 그 자체의 인스턴스를 초기화 하고 그것의 식별자 프로퍼티들을 군집화 시켜야 한다. 우리는 이 접근법을 embedded composite 식별자로 부르고, 중대한 어플리케이션들에 대해 그것을 억제시킨다. 두 번째 접근법은 우리가 mapped composite 식별자라고 부르는 것인데, 여기서 <composite-id> 요소 내에 명명된 여기서 식별자 프로퍼티들은 영속 클래스와 별도의 식별자 클래스 양자 상에 중복된다. ]]> 이 예제에서, composite 식별자 클래스인 MedicareId와 엔티티 크래스 그 자체 양자는 medicareNumber와 dependent로 명명된 프로퍼티들을 갖는다. 식별자 클래스는 equals()와 hashCode()를 오버라이드 시켜고 Serializable을 구현해야 한다. 이 접근법의 단점은 아주 명백한—코드 중복이다. 다음 속성들은 매핑된 composite 식별자를 지정하는데 사용된다: mapped (옵션, 디폴트는 false): 하나의 매핑된 composite 식별자가 사용됨을, 그리고 포함된 프로퍼티 매핑들이 엔티티 클래스와 composite 식별자 클래스 양자를 참조함을 나타낸다. class (옵션, 하지만 하나의 매핑된 commposite 식별자에 대해서는 필수적임): 하나의 composite 식별자로서 사용되는 클래스. 우리는 에서 composite 식별자가 하나의 component 클래스로서 구현되는 보다 편리한 접근법인 세번째 방도를 설명할 것이다. 아래에 설명되어 있는 속성들은 이 대체적인 접근법에만 적용된다: name (옵션, 이 접근법의 경우에는 필수임): 하나의 component 식별자를 소유하는 컴포넌트 타입의 프로퍼티(9장을 보라). access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 하나의 composite 식별자로서 사용되는 컴포넌트 클래스(다음 절을 보라). 이 세번째 접근법, identifier component은 거의 모든 어플리케이션들에 대해 우리가 권장하는 것이다. <discriminator> 요소는 table-per-class-hierarchy(테이블 당 클래스 계층구조) 매핑 방도를 사용하는 다형성 영속화에 필요하고 테이블의 discriminator(판별자) 컬럼을 선언한다. discriminator 컬럼은 특정 행에 대해 초기화 시킬 서브 클래스가 무엇인지를 영속 계층에 알려주는 표시자 값들을 포함한다. 타입들의 제한적인 집합이 사용될 수 있다: string, character, integer, byte, short, boolean, yes_no, true_false. ]]> column (옵션 - 디폴트는 class) discriminator 컬럼명. type (옵션 - 디폴트는 string) Hibernate 타입을 나타내는 이름 force (옵션 - 디폴트는 false) 이것은 Hibernate로 하여금 루트 클래스의 모든 인스턴스들을 검색할 때조차도 허용된 discriminator 값들을 지정하도록 "강제한다". insert (옵션 - 디폴트는 true) 당신의 discriminator 컬럼이 또한 매핑된 composite 식별자의 부분일 경우에 이것을 false로 설정하라. (Hibernate에게 SQL INSERT들 속에 그 컬럼을 포함하지 않도록 통보한다.) formula (옵션) 타입이 평가 되어야 할 때 실행되는 임의의 SQL 표현식. 컨텐츠 기반의 판별을 허용해준다. discriminator 컬럼의 실제 값들은 <class> 요소와 <subclass> 요소의 discriminator-value 속성에 의해 지정된다. force 속성은 테이블이 영속 클래스로 매핑되지 않는 "특별한" discriminator 값들을 가진 행들을 포함할 경우에(만) 유용하다. 이것은 대개 그 경우가 아닐 것이다. formula 속성을 사용하여 당신은 행의 타입을 판단하는데 사용될 임의의 SQL 표현식을 선언할 수 있다: ]]> <version> 요소는 옵션이고 테이블이 버전화된 데이터를 포함한다는 것을 나타낸다. 이것은 당신이 긴 트랜잭션(long transaction)들을 사용할 계획이라면 특히 유용하다 (아래를 보라). ]]> column (옵션 - 디폴트는 프로퍼티 명): 버전 번호를 가진 컬럼의 이름. name: 영속 클래스의 프로퍼티 명. type (옵션 - 디폴트는 integer): 버전 번호의 타입. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. unsaved-value (옵션 - 디폴트는 undefined): 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 구별지어서, 인스턴스가 새로이 초기화됨(unsaved)을 나타내는 version 프로퍼티 값.(undefined는 식별자 프로퍼티 값이 사용될 것임을 지정한다.) generated (옵션 - 디폴트는 false): 이 version 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다. 산출되는 프로퍼티들에 관한 논의를 보라. insert (옵션 - 디폴트는 true): version 컬럼이 SQL insert 문장들 속에 포함될 것인지 여부를 지정한다. 데이터베이스 컬럼이 디폴트 값 0으로 정의되는 경우에만 false로 설정될 수 있다. 버전 번호들은 long, integer, short, timestamp 또는 calendar 타입일 수 있다. version 또는 timestamp 프로퍼티는 detached 인스턴스에 대해 결코 null일 수가 없어서, Hibernate는 다른 unsaved-value 방도들이 지정되는 것에 상관없이, null version이나 timestamp를 가진 임의의 인스턴스를 transient로서 검출할 것이다. null 허용되는 version 이나 property를 선언하는 것은 Hibernate에서 transitive reattachment에 대한 임의의 문제들을 피하는 쉬운 방법이고, assigned 식별자들이나 composite key들을 사용하는 사람들에게 특히 유용하다! 옵션 <timestamp> 요소는 테이블이 타임스탬프화 된 데이터를 포함함을 나타낸다. 이것은 버전화에 대한 대체물로서 고안되었다. Timestamp은 고유하게 optimistic 잠금에 대한 다소 안전한 구현이다. 하지만 때때로 어플리케이션은 다른 방법들로 timestamp들을 사용할 수도 있다. ]]> column (옵션 - 디폴트는 프로퍼티 명): 타임스탬프를 포함하는 컬럼 명. name: 영속 클래스에 대해 자바 Date 또는 Timestamp 타입을 가진 자바빈즈 스타일의 프로퍼티 이름. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. unsaved-value (옵션 - 디폴트는 null): 이전 세션에서 저장되었거나 로드되었던 detached 인스턴스로부터 인스턴스를 구별지우는, 인스턴스가 새로이 초기화됨(unsaved)을 나타내는 version 프로퍼티 값.(undefined는 식별자 프로퍼티 값이 사용될 것임을 지정한다.) source (옵션 - 디폴트는 vm): Hibernate는 어느 장소로부터 timestamp 값을 검색할 것인가? 데이터베이스로부터인가 현재의 JVM으로부터인가? Hibernate가 "다음 값"을 결정하기 위해 데이터베이스에 접속해야 하기 때문에 데이터베이스 기반의 timestamp들은 오버헤드를 초래하지만, 클러스터링된 환경들의 용도로 더 안전할 것이다. 또한 모든 Dialect들이 데이터베이스의 현재의 timestamp에 대한 검색을 지원하는 것으로 알려져 있는 반면에, 다른 Dialect들은 정밀도 결핍 때문에 잠금에 있어 사용에 대해 안전하지 않을 수 있음을 노트하라(예를 들면 오라클 8). generated (옵션 - 디폴트는 false): 이 timestamp 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다. 산출되는 프로퍼티들에 대한 논의들 보라. <timestamp>는 <version type="timestamp">과 같음을 노트하라. 그리고 <timestamp use-db="true">는 <version type="dbtimestamp">과 같다 <property> 요소는 클래스의 자바빈즈 스타일의 영속 프로퍼티를 선언한다. ]]> name: 첫 소문자로 시작하는 프로퍼티 이름. column (옵션 - 디폴트는 프로퍼티 이름): 매핑된 데이터베이스 테이블 컬럼의 이름. 이것은 또한 내부에 포함되는 <column> 요소(들)에 의해 지정될 수도 있다. type (옵션): Hibernate 타입을 나타내는 이름. update, insert (옵션 - 디폴트는 true) : 매핑된 컬럼들이 UPDATE와/또는 INSERT 문장들속에 포함될 것임을 지정한다. 둘다 false로 설정하는 것은 그 값이 동일한 컬럼(들)로 매핑되는 어떤 다른 프로퍼티로부터 또는 트리거에 의해 또는 다른 어플리케이션으로부터 초기화 되는 순수하게 "파생된(derived)" 프로퍼티를 허용해준다. formula (옵션): 계산되는 프로퍼티에 대해 값을 정의하는 SQL 표현식. 계산되는 프로퍼티들은 그것들 자신에 대한 컬럼 매핑을 갖지 않는다. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. lazy (옵션 - 디폴트는 false): 인스턴스 변수가 처음으로 액세스 될 때 이 프로퍼티가 lazily하게 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다). unique (옵션): 컬럼들에 대한 유일 컨스트레인트의 DDL 생성을 가능하게 만든다. 또한 이것이 property-ref의 타켓이 되는 것을 허용해준다. not-null (옵션): 컬럼들에 대해 null 가능 컨스트레인트의 DDL 생성을 가능하게 만든다. optimistic-lock (옵션 - 디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하거나 필요로 하지 않음을 지정한다. 달리말해, 이 프로퍼티가 dirty일 때 버전 증가가 발생할 경우인지를 결정한다. generated (옵션 - 디폴트는 false): 이 프로퍼티 값이 데이터베이스에 의해 실제로 산출되는지를 지정한다. 산출되는 프로퍼티들에 대한 논의를 보라. typename은 다음일 수 있다: Hibernate 기본 타입의 이름 (예를 들어. integer, string, character, date, timestamp, float, binary, serializable, object, blob). 디폴트 기본 타입을 가진 Java 클래스의 이름(예를 들어. int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob). serializable Java 클래스의 이름. 맞춤 타입의 클래스 이름(예를 들어. com.illflow.type.MyCustomType). 만일 당신이 타입을 지정하지 않을 경우, Hibernate는 정확한 Hibernate 타입을 추정하기 위해 명명된 프로퍼티에 대해 reflection을 사용할 것이다. Hibernate는 그 순서에서 2,3,4 규칙들을 사용하여 프로퍼티 getter의 반환 클래스의 이름을 해석하려고 시도할 것이다. 하지만 이것은 항상 충분하지는 않다. 어떤 경우들에서, 당신은 여전히 type 속성을 필요로 할 것이다.(예를 들어, Hibernate.DATE와 Hibernate.TIMESTAMP 사이를 구별하기 위해, 또는 맞춤 타입을 지정하기 위해.) access 속성은 당신으로 하여금 Hibernate가 런타임 시에 프로퍼티에 액세스하는 방법을 제어하도록 해준다. 디폴트로 Hibernate는 프로퍼티 get/set 쌍을 호출할 것이다. 만일 당신이 access="field"를 지정할 경우, Hibernate는 get/set 쌍을 피하고 reflection을 사용하여 직접 필드에 액세스 할 것이다. 당신은 org.hibernate.property.PropertyAccessor 인터페이스를 구현하는 클래스를 명명함으로써 프로퍼티 접근을 위한 당신 자신의 방도를 지정할 수도 있다. 특별히 강력한 특징은 파생된 플로퍼티들이다. 이들 프로퍼티들은 정의상 읽기 전용이고, 그 프로퍼티 값은 로드 시에 계산된다. 당신은 그 계산을 SQL 표현식으로 선언하고, 이것은 인스턴스를 로드시키는 SQL 질의 내의 SELECT 절 서브질의로 번역된다: ]]> 당신은 특정 컬럼(주어진 예제에서는 customerId)에 대해 alias를 선언하지 않음으로써 엔티티들 자신의 테이블을 참조할 수 있음을 노트하라. 또한 당신은 만일 당신이 그 속성을 사용하고 싶지 않을 경우에 내포된 <formula> 매핑 요소를 사용할 수 있음을 노트하라. 또 다른 영속 클래스에 대한 정규 연관관계는 many-to-one 요소를 사용하여 선언된다. 관계형 모형은 many-to-one 연관관계이다.: 하나의 테이블 내에 있는 foreign 키는 대상 테이블의 프라이머리 키 컬럼(들)을 참조하고 있다. ]]> name: 프로퍼티의 이름. column (옵션): foreign key 컬럼의 이름. 이것은 또한 내포된 <column> 요소(들)에 의해 지정된다. class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 연관된 클래스의 이름. cascade (옵션): 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 케스케이드 될 것인지를 지정한다. fetch (옵션 - 디폴트는 select): outer-join 페칭 또는 sequential select 페칭 사이에서 선택하라. update, insert (옵션 - 디폴트는 true) 매핑된 컬럼들이 SQL UPDATE와/또는 INSERT 문장들 속에 포함될 것인지를 지정한다. 둘다 false로 설정하는 것은 그 값이 동일한 컬럼(들)로 매핑시키는 어떤 다른 컬럼들로부터 초기화 되거나 트리거나 다른 어플리케이션에 의해 초기화되는 단순한 "파생된" 연관관계 값을 허용한다. property-ref: (옵션) 이 foreign key에 조인되는 연관된 클래스의 프로퍼티 이름. 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. unique (옵션): foreign-key 컬럼을 위한 유일 컨스트레인트의 DDL 생성을 가능하도록 해준다. 또한 이것이 property-ref의 대상이 되는 것을 허용해준다. 이것은 연관 다중성(association multiplicity)을 효율적으로 일 대 일로 만든다. not-null (옵션): foreign key 컬럼들을 위한 null 가능한 컨스트레인트의 DDL 생성을 가능하도록 해준다. optimistic-lock (옵션 - 디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic lock의 획득을 필요로 하는지 아닌지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty일 때 version 증가가 발생해야 할 경우인지를 결정한다. lazy (옵션 - 디폴트는 proxy): 디폴트로, 단일 포인트 연관들이 프락시된다. lazy="no-proxy"는 인스턴스 변수가 처음으로 접근될 때 그 프로퍼티가 lazily 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다). lazy="false"는 그 연관이 항상 eagerly 페치될 것임을 지정한다. not-found (옵션 - 디폴트는 exception): 누락된 행들을 참조하는 foreign key들이 어떻게 처리될 것인지를 지정한다: ignore는 한 개의 누락된 행을 한 개의 null 연관으로 취급할 것이다. entity-name (옵션): 연관된 클래스의 엔티티 이름. formula (옵션): 계산된 foreign key에 대한 값을 정의하는 SQL 표현식. cascade 속성 값을 none 아닌 어떤 의미있는 다른 값으로 설정하는 것은 어떤 오퍼레이션들을 연관된 객체에게 보급할 것이다. 유의미한 값들은 Hibernate의 기본 오퍼레이션들의 이름들, 즉 persist, merge, delete, save-update, evict, replicate, lock, refresh 뿐만 아니라 특별한 값들, 즉 delete-orphan과 all 그리고 오퍼레이션 이름들의 쉼표 분리된 조합들, 예를 들면 cascade="persist,merge,evict" 또는 cascade="all,delete-orphan"이다. 전체 설명은 를 보라. 단일값 연관들(many-to-one 연관과 one-to-one 연관)은 orphan delete를 지원하지 않음을 노트하라. 일반적인 many-to-one 선언은 다음과 같이 간단하게 보여진다: ]]> property-ref 속성은 오직 foreign key가 프라이머리 키가 아닌 연관된 테이블의 유일 키를 참조하는 리거시 데이터를 매핑하는데만 사용된다. 이것은 꼴사나운 관계형 모형이다. 예를 들어, Product 클래스가 프라이머리 키를 아닌, 유일한 시리얼 번호를 갖는다고 가정하자.(unique 속성은 SchemaExport 도구로 Hibernate의 DDL 생성을 제어한다.) ]]> 그런 다음 OrderItem에 대한 매핑은 다음을 사용할 것이다: ]]> 하지만 이것은 확실히 권장되지 않는다. 만일 참조된 유일 키가 연관된 엔티티의 여러 프로퍼티들을 포함할 경우, 당신은 명명된 <properties> 요소 내부에 참조된 프로퍼티들을 매핑할 것이다. 만일 참조된 유일키가 컴포넌트의 프로퍼티일 경우, 당신은 하나의 프로퍼티 경로를 지정할 수 있다: ]]> 또 다른 영속 클래스에 대한 one-to-one 연관관계는 one-to-one 요소를 사용하여 선언된다. ]]> name: 프로퍼티의 이름. class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 연관된 클래스의 이름. cascade (옵션) 어느 오퍼레이션들이 부모 객체로부터 연관된 객체로 케스케이드 될 것인지를 지정한다. constrained (옵션) 매핑된 테이블의 프라이머리 키에 대한 foreign 키 컨스트레인트가 연관된 클래스의 테이블을 참조하는지 여부를 지정한다. 이 옵션은 save()와 delete()가 케스케이드 되는 순서에 영향을 주고, 그 연관이 프락시 될 것인지 여부를 결정한다 (또한 스키마 내보내기 도구에 의해 사용된다). fetch (옵션 - 디폴트는 select): outer-join 페칭 또는 순차적인 select 페칭 중에서 선택하라. property-ref: (옵션) 이 클래스의 프라이머리 키에 연결된 연관 클래스의 프로퍼티의 이름. 만일 지정되지 않을 경우, 연관 클래스의 프라이머리 키가 사용된다. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근 하는데 사용할 방도. formula (옵션): 거의 모든 one to one 연관관계들은 소유하는 엔티티의 프라이머리 키로 매핑된다. 이것이 그 경우가 아닌 드문 경우들에서, 당신은 SQL formula 사용에 결합시킬 몇몇 다른 컬럼, 컬럼들, 또는 표현식을 지정할 수 있다.(예제는 org.hibernate.test.onetooneformula를 보라.) lazy (옵션 - 디폴트는 proxy): 디폴트로 한쪽 끝 연관들이 프락시 된다. lazy="no-proxy"는 인스턴스 변수가 처음 접근될 때 그 프로퍼티가 lazily 페치될 것임을 지정한다(빌드-시 바이트코드 수단을 필요로 한다). lazy="false"는 그 연관들이 항상 eagerly 페치될 것임을 지정한다. 만일 constrained="false"인 경우에, 프락싱은 불가능하고 Hibernate는 그 연관을 eager 페치시킬 것이다! entity-name (옵션): 연관된 클래스의 엔티티 이름. one-to-one 연관관계에는 두 가지 변종이 존재한다: 프라이머리 키 연관관계들 유일 foreign 키 연관관계들 프라이머리 키 연관들은 특별한 테이블 컬럼을 필요로 하지 않는다; 만일 두 개의 행들이 그 연관에 의해 관계지워지면, 두 개의 테이블 행들은 동일한 프라이머리 키 값을 공유한다. 따라서 만일 두 개의 객체들이 프라이머리 키 연관에 의해 관계지워지도록 당신이 원할 경우, 당신은 그것들에 동일한 식별자 값이 할당되도록 해야 한다! 프라이머리 키 연관에 대해, 다음 매핑들을 Employee와 Person 각각에 추가하라. ]]> ]]> 이제 우리는 PERSON 과 EMPLOYEE 테이블들에서 관계지워진 행들의 프라이머리 키들이 동일함을 확실히 해야 한다! 우리는 foreign로 명명되는 특별한 Hibernate 식별자 생성 방도를 사용한다: employee ... ]]> 그때 Person의 새로이 저장된 인스턴스는 그 Person의 employee 프로퍼티에 대해 참조된 Employee 인스턴스와 동일한 프라이머리 키를 할당받는다. 달리, Employee로부터 Person으로의 유일 컨스트레인트를 가진 하나의 foreign key는 다음과 같이 표현될 수 있다: ]]> 그리고 이 연관은 다음을 Person 매핑에 추가함으로써 양방향이 될 수 있다: ]]> ...... ]]> 비록 우리가 프라이머리 키들로서 대용키들을 사용하는 것을 권장했을지라도, 당신은 여전히 모든 엔티티들에 대한 natural 키들을 식별하고자 원할 것이다. narutal 키는 유일(unique)하고 null이 아닌 프로퍼티 또는 프로퍼티들의 조합이다. 그것이 또한 불변하는 것일 경우가 더 좋다. <natural-id> 요소 내부에 있는 natural 키의 프로퍼티들을 매핑하라. Hibernate는 필수적인 유일 키와 null 허용가능한 컨스트레인트들을 생성시킬 것이고, 당신의 매핑은 보다 자가 설명적이게 될 것이다. 우리는 당신이 엔티티에 대한 narutal 키 프로퍼티들을 비교하는데 equals()와 hashCode()를 구현할 것을 강력하게 권장한다. 이 매핑은 natural 프라이머리 키들을 가진 엔티티들을 위한 용도로 고안된 것은 아니다. mutable (옵션, 디폴트는 false): 디폴트로, narutal 식별자 프로퍼티들은 변경될 수 없는 것(상수)으로 가정된다. <component> 요소는 자식 객체의 프로퍼티들을 부모 클래스에 대한 테이블의 컬럼들로 매핑시킨다. 컴포넌트들은 그것들 자신의 프로퍼티들, 컴포넌트들, 또는 콜렉션들을 선언한다. 이래 "컴포넌트들"을 보라. ........ ]]> name: 프로퍼티의 이름. class (옵션 - 디폴트는 reflection에 의해 결정된 프로퍼티 타입): 컴포넌트(자식) 클래스의 이름. insert: 매핑된 컬럼들이 SQL INSERT들 속에 나타나야 하는가? update: 매핑된 컬럼들이 SQL UPDATE들 속에 나타나야 하는가? access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 액세스하는데 사용할 방도. lazy (옵션 - 디폴트는 false): 인스턴스 변수가 처음으로 액세스될 때 이 컴포넌트가 lazily(느리게) 페치되어야 하는지 여부를 지정한다 (빌드 시 바이트코드 수단을 필요로 한다). optimistic-lock (옵션 - 디폴트는 true): 이 컴포넌트에 대한 업데이트들이 optimistic 잠금을 획득하는 것을 필요로 하는지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다. unique (옵션 - 디폴트는 false): 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다. 자식 <property> 태그들은 자식 클래스의 프로퍼티들을 테이블 컬럼들로 매핑시킨다. <component> 요소는 컴포넌트 클래스의 프로퍼티를 포함하는 엔티티에 대한 참조로서 매핑시키는 <parent> 서브요소를 허용한다. <dynamic-component> 요소는 컴포넌트로서 매핑될Map을 허용한다. 여기서 프로퍼티 이름들은 map의 키들을 참조한다. 을 보라. <properties> 요소는 클래스의 프로퍼티들의 명명된, 논리적 그룹핑에 대한 정의를 허용한다. 그 구조에 대한 가장 중요한 사용은 그것이 프로퍼티들의 조합이 property-ref의 대상이 되는 것을 허용해준다는 점이다. 또한 그것은 다중 컬럼 유일 컨스트레인느를 정의하는 편리한 방법이다. ........ ]]> name: 그룹핑의 논리적 이름 - 실제 프로퍼티 이름이 아니다. insert: 매핑된 컬럼들이 SQL INSERT들 내에 나타날 것인가? update: 매핑된 컬럼들이 SQL UPDATE들 내에 나타날 것인가? optimistic-lock (옵션 - 디폴트는 true): 이들 프로퍼티들에 대한 업데이트들이 optimistic 잠금의 획득을 필요로 하는지 여부를 지정한다. 달리 말해 이 프로퍼티가 dirty 일 때 버전 증가가 발생할 것인지 여부를 결정한다. unique (옵션 - 디폴트는 false): 유일 컨스트레인트가 컴포넌트의 모든 매핑된 컬럼들에 대해 존재하는지 여부를 지정한다. 예를 들어, 만일 우리가 다음 <properties> 매핑을 가질 경우: ... ]]> 그 때 우리는 프라이머리 키가 아닌, Person 테이블의 이 유일 키를 참조하는 어떤 리거시 데이터 연관을 가질 수 있다: ]]> 우리는 리거시 데이터를 매핑시키는 컨텍스트 바깥에서 이런 종류의 것을 사용하는 것을 권장하지 않는다. 마지막으로, 다형성 영속성은 루트 영속 클래스에 대한 각각의 서브클래스 선언을 필요로 한다.(권장되는) table-per-class-hierarchy(테이블 당 클래스 계층구조) 매핑 방도의 경우, <subclass> 선언이 사용된다. ..... ]]> name: 서브클래스의 전체 수식어가 붙은 클래스 이름. discriminator-value (옵션 - 디폴트는 클래스 이름): 개개의 서브클래스들을 구분짓는 값. proxy (옵션): lazy 초기화 프락시들을 사용하는데 클래스 또는 인터페이스를 지정한다. lazy (옵션 - 디폴트는 true): lazy="false" 설정은 lazy 페칭의 사용을 불가능하게 만든다. 각각의 서브클래스는 그것 자신의 영속 프로퍼티들과 서브클래스들을 선언할 것이다. <version> 프로퍼티와 <id> 프로퍼티는 루트 클래스로부터 상속된다고 가정된다. 계층구조 내에서 각각의 서브클래스는 유일한 discriminator-value를 정의해야 한다. none이 지정될 경우, 전체 수식어가 붙은 자바 클래스 이름이 사용된다. 상속 매핑들에 대한 정보는 을 보라. 다른 방법으로 각각의 서브클래스는 그것 자신이 테이블로 매핑될 수 있다(table-per-subclass 매핑 방도). 상속된 상태는 슈퍼클래스의 테이블과 조인함으로써 검색된다. 우리는 <joined-subclass> 요소를 사용한다. ..... ]]> name: 서브클래스의 전체 수식어가 붙은 클래스 명. table: 서브클래스 테이블의 이름. proxy (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다. lazy (옵션 - 디폴트는 true): lazy="false" 설정은 lazy 페칭을 사용불가능하게 만든다 판별자(discriminator) 컬럼은 이 매핑 방도에 필요하지 않다. 하지만 각각의 서브클래스는 <key> 요소를 사용하여 객체 식별자를 보관하는 테이블 컬럼을 선언해야 한다. 이 장의 시작 부분에 있는 매핑은 다음과 같이 다시 작성될 것이다: ]]> 상속 매핑들에 대한 정보는 을 보라. 제3의 옵션은 상속 계층구조의 concrete 클래스들 만을 테이블들로 매핑하는 것이다 (table-per-concrete-class 방도). 여기서 각각의 테이블은 상속된 상태를 포함하여 클래스의 모든 영속 상태를 정의한다. Hibernate에서, 그것은 그런 상속 계층구조들을 명시적으로 매핑하는데 필수적이지 않다. 당신은 별도의 <class> 선언을 가진 각각의 클래스를 간단히 매핑시킬 수 있다. 하지만 당신이 다형성 연관관계들(예를 들면 당신의 계층구조의 슈퍼클래스에 대한 연관)을 사용하고자 원할 경우, 당신은 <union-subclass> 매핑을 사용할 필요가 있다. ..... ]]> name: 서브클래스의 전체 수식어가 붙은 클래스 명. table: 서브클래스 테이블의 이름. proxy (옵션): 프락시들을 lazy 초기화 시키는데 사용할 클래스 또는 인터페이스를 지정한다. lazy (옵션 - 디폴트는 true): lazy="false" 설정은 lazy 페칭을 사용불가능하게 만든다. 이 매핑 방도에는 판별자 컬럼이나 키 컬럼이 필요하지 않다. 상속 매핑들에 대한 정보는 을 보라. <join> 요소를 사용하면, 한 개의 클래스의 프로퍼티들을 몇 개의 테이블들로 매핑시키는 것이 가능하다. ... ]]> table: 조인된 테이블의 이름. schema (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 스키마 이름을 오버라이드 시킨다 catalog (옵션): 루트 <hibernate-mapping> 요소에 의해 지정된 카타록 이름을 오버라이드 시킨다. fetch (옵션 - 디폴트는 join): join으로 설정될 경우, 디폴트로 Hibernate는 하나의 클래스 또는 그것의 슈퍼 클래스들에 의해 정의된 <join>을 검색하는데 inner join을 사용하고 서브클래스에 의해 정의된 <join>을 검색하는데 outer join을 사용할 것이다. 만일 select로 설정할 경우, Hibernate는 서브클래스 상에 정의된 <join>에 대해 sequential select를 사용할 것이고, 그것은 한 행이 서브클래스의 인스턴스를 표현하는 것으로 판명되는 경우에만 명령이 내려질 것이다. inner join들은 여전히 클래스와 그것의 슈퍼클래스들에 의해 정의된 <join>을 검색하는데 사용될 것이다. inverse (옵션 - 디폴트는 false): 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들을 삽입시키거나 업데이트하려고 시도하지 않을 것이다. optional (옵션 - 디폴트는 false): 이용 가능할 경우, Hibernate는 이 조인에 의해 정의된 프로퍼티들이 null이 아닐 경우에만 한 행을 삽입시킬 것이고 그 프로퍼티들을 검색하는데 outer join을 항상 사용할 것이다. 예를 들어, (모든 프로퍼티들에 대해 value 타입 의미를 유지하면서) 개인의 주소 정보는 별도의 테이블에 매핑될 수 있다: ... ...]]> 이 특징은 자주 리거시 데이터 모형들에 대해서만 유용하고, 우리는 클래스들과 잘 정제된 도메인 모형 보다 더 적은 테이블들을 권장한다. 하지만 뒷 부분에 설명되어 있듯이, 그것은 하나의 계층구조 내에 있는 상속 매핑 방도들 사이를 전환하는 것에 유용하다. 우리는 지금까지 몇 번 나타났던 <key> 요소를 보았다. 그것은 부모 매핑 요소가 새로운 테이블에 대한 조인을 정의하는 어느 곳에서나 나타나고, 그것은 조인된 테이블의 foreign 키를 정의하고, 그것은 원래의 테이블의 프라이머리 키를 참조한다. ]]> column (옵션): foreign key 컬럼의 이름. 이것은 또한 내포된 <column> 요소(들)에 의해 지정될 수 있다. on-delete (옵션 - 디폴트는 noaction): foreign key 컨스트레인트가 데이터베이스 레벨의 cascade delete를 사용가능하도록 할 것인지 여부를 지정한다. property-ref (옵션): foreign key가 원래의 테이블의 프라이머리 키가 아닌 컬럼들을 참조함을 지정한다. (리거시 데이터에 제공됨.) not-null (옵션): foreign 키 컬럼들이 not null 임를 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다). update (옵션): foreign 키가 결코 업데이트되지 않아야 함을 지정한다(이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다). unique (옵션): foreign 키가 유일 컨스트레인트를 가져야 함을 지정한다 (이것은 foreign 키가 또한 프라이머리 키의 부분일 때마다 함축된다). 우리는 delete 퍼포먼스가 중요한 시스템들에 대해 권장하고, 모든 키들은 on-delete="cascade"로 정의되고, Hibernate는 많은 DELETE 문장들 대신에, 데이터베이스 레벨의 ON CASCADE DELETE 컨스트레인트를 사용할 것이다. 이 특징은 Hibernate의 통상적인 버전화된 데이터에 대한 optimistic 잠금 방도를 무시한다는 점을 알고 있어라. not-null 속성과 update 속성들은 단방향 one to many 연관관계를 매핑할 때 유용하다. 만일 당신이 단방향 one to many를 null이 허용되지 않는 foreign 키로 매핑할 경우, 당신은 <key not-null="true">를 사용하여 그 키 컬럼을 선언해야 한다. column 속성을 허용하는 임의의 매핑 요소는 대안적으로 하나의 <column> 서브요소를 수용할 것이다. 비슷하게 <formula>는 formula 속성에 대한 대안이다. ]]> SQL expression]]> column 속성과 formula 속성은 예를 들어 신종 조인 조건들을 표현하기 위해 동일한 property 또는 연관관계 매핑 내에 결합될 수 있다. 'MAILING' ]]> 당신의 어플리케이션이 동일한 이름을 가진 두 개의 영속 클래스들을 갖고, 당신이 Hibernate 질의들 내에서 전체 수식어가 붙은 (패키지)이름을 지정하는 것을 원하지 않는다고 가정하자. 클래스들은 auto-import="true"에 의존하기 보다 명시적으로 "임포트 될 " 것이다. 당신은 심지어 명시적으로 매핑되지 않는 클래스들과 인터페이스들을 임포트 시킬 수(가져오기 할 수) 있다. ]]> ]]> class: 임의의 Java 클래스의 전체 수식어가 붙은 클래스 이름. rename (옵션 - 디폴트는 수식어가 붙지 않은 클래스 이름): 질의 언어 내에서 사용될 이름. 하나 이상의 프로퍼티 매핑 타입이 존재한다. <any> 매핑 요소는 여러 테이블들로부터 클래스들에 대한 하나의 다형성 연관관계를 정의한다. 이 매핑 타입은 언제나 하나 이상의 컬럼을 필요로 한다. 첫 번째 컬럼은 연관된 엔티티의 타입을 보관한다. 나머지 컬럼들은 식별자를 보관한다. 이런 종류의 연관관계들에 대해 foreign key 컨스트레인트를 지정하는 것이 불가능해서, 이것은 (다형성) 연관관계들을 매핑하는 통상적인 방법으로서 가장 확실한 수단이 아니다. 당신은 매우 특별한 경우들 (예를 들어 감사 로그들, 사용자 세션 데이터 등)에서만 이것을 사용해야 한다. meta-type 속성은 어플리케이션으로 하여금 데이터베이스 컬럼 값들을 id-type에 의해 지정된 타입의 식별자 프로퍼티들을 가진 영속 클래스들로 매핑시키는 맞춤형 타입을 지정하도록 한다. 당신은 meta-type의 값들로부터 클래스 이름들로의 매핑을 지정해야 한다. ]]> ..... ..... ]]> name: 프로퍼티 이름. id-type: 식별자 타입. meta-type (옵션 - 디폴트는 string): discriminator 매핑에 허용되는 임의의 타입. cascade (optional- defaults to none): cascade 스타일. access (옵션 - 디폴트는 property): Hibernate가 프로퍼티 값에 접근하는데 사용할 방도. optimistic-lock (옵션 - 디폴트는 true): 이 프로퍼티에 대한 업데이트들이 optimistic 잠금 획득을 필요로 하는지 여부를 지정한다. 달리 말해, 이 프로퍼티가 dirty일 경우에 버전증가가 발생할 것인지 여부를 정의한다. 영속 서비스에 관한 여러 Java 언어-레벨의 객체들을 이해하기 위해, 우리는 그것들을 다음 두 개의 그룹들로 분류할 필요가 있다: entity는 엔티티에 대한 참조들을 보관하는 임의의 다른 객체들과는 독립적으로 존재한다. 참조되지 않은 객체가 쓰레기 수집되는 통상의 자바 모형과 이것은 대조적이다. (저장들과 삭제들이 부모 엔티티로부터 그것의 자식으로의 케스케이드 되는 경우를 제외하면) 엔티티들은 명시적으로 저장되고 삭제되어야 한다. 이것은 도달 가능성(reachablity)에 의한 객체 영속성의 ODMG 모형과는 다르다 - 그리고 어플리케이션 객체들이 대형 시스템들에서 대개 어떻게 사용되는가에 훨씬 더 가깝게 대응한다. 엔티티들은 순환 참조와 공유 참조들을 지원한다. 그것들 또한 버전화 될 수 있다. 엔티티의 영속 상태는 다른 엔티티들에 대한 참조들과 value 타입들로 구성된다. 값들은 원시 타입들, 콜렉션들(하나의 콜렉션 내부에 있지 않는 것들), 컴포넌트들, 그리고 어떤 불변의 객체들이다. entities와는 달리, (특별한 콜렉션들과 컴포넌트들에서) 값들은 도달가능성(reachability)에 의해 영속화 되고 삭제 된다. value 객체들(과 원시 타입들)이 그것들의 포함하는 엔티티에 따라 영속화 되고 삭제 되므로, 그것들은 독립적으로 버전화 되지 않는다. 값들은 독립적인 엔티티를 갖지 않아서, 그것들은 두 개의 엔티티들이나 콜렉션들에 의해 공유될 수 없다. 지금까지 우리는 엔티티들을 참조하기 위해 "영속 클래스"를 사용해 왔다. 우리는 그것을 계속 사용할 것이다. 하지만 엄격히 말해, 영속 상태를 가진 모든 사용자 정의 클래스들은 엔티티들이 아니다. 컴포넌트는 value 의미를 가진 사용자 정의 클래스이다. java.lang.String 타입의 자바 프로퍼티는 또한 value 의미를 갖는다. 이 정의가 주어지면, 우리는 JDK에 의해 제공된 모든 타입들(클래스들)이 자바에서 value 타입 의미를 갖고, 반면에 사용자 정의 타입들은 엔티티 또는 type 의미로서 매핑된다고 말할 수 있다. 이 판단은 어플리케이션 개발자에게 달려 있다. 도메인 모형에서 엔티티 클래스에 대한 좋은 힌트는 그 클래스의 하나의 인스턴스에 대한 공유된 참조들인 반면에, composition이나 aggregation은 대개 value 타입으로 변환된다. 우리는 문서를 통해 두 개념들을 다시 고찰할 것이다. 도점점은 Java type 시스템(과 엔티티들 및 value 타입들에 대한 개발자의 정의)를 SQL/데이터베이스 type 타입으로 매핑하는 것이다. 두 시스템들 사이의 다리는 Hibernate에 의해 제공된다: 엔티티들의 경우 우리는 <class>, <subclass> 등을 사용한다.value 타입들의 경우 우리는 대개type 속성을 가진 <property>, <component> 등을 사용한다. 이 속성의 값은 Hibernate 매핑 타입의 이름이다. Hibernate는 (표준 JDK value 타입들에 대해) 많은 매핑들을 제공한다. 나중에 보게 되듯이, 당신은 당신 자신의 매핑 타입들을 작성할 수 있고 마찬가지로 당신의 맞춤형 변환 방도들을 구현할 수 있다. 콜렉션들을 제외한 모든 미리 빌드된 Hibernate 타입들은 null 의미를 지원한다. 미리-만들어진 기본 매핑 타입들은 대략 다음과 같이 카테고리로 분류된다 integer, long, short, float, double, character, byte, boolean, yes_no, true_false 자바 원시타입들이나 wrapper 클래스들로부터 적절한(벤더-지정적인) SQL 컬럼 타입들로의 타입 매핑. boolean, yes_no와 true_false는 Java boolean이나 java.lang.Boolean에 대한 모든 대체적인 인코딩들이다. string java.lang.String으로부터 VARCHAR (또는 Oracle VARCHAR2)로의 타입 매핑. date, time, timestamp java.util.Date와 그것의 서브클래스로부터 SQL 타입들인 DATE, TIME, TIMESTAMP (또는 등가물)로의 타입 매핑들. calendar, calendar_date java.util.Calendar로부터 SQL 타입들인 TIMESTAMP, DATE (또는 등가물)로의 타입 매핑들. big_decimal, big_integer java.math.BigDecimal과 java.math.BigInteger로부터 NUMERIC (또는 Oracle NUMBER)로의 타입 매핑들. locale, timezone, currency java.util.Locale, java.util.TimeZone, 그리고 java.util.Currency로부터 VARCHAR(또는 Oracle VARCHAR2)로의 타입 매핑. Locale과 Currency의 인스턴스들은 그것들의 ISO 코드들로 매핑된다. TimeZone의 인스턴스들은 그것들의 ID로 매핑된다. class java.lang.Class로부터 VARCHAR (또는 Oracle VARCHAR2)로의 타입 매핑. Class는 그것의 전체 수식어가 붙은 이름으로 매핑된다. binary byte 배열들을 적절한 SQL binary 타입으로 매핑시킨다. text long Java 문자열을 SQL CLOB 또는 TEXT 타입으로 매핑시킨다 serializable serializable Java 타입들을 적절한 SQL binary 타입으로 매핑시킨다. 당신은 또한 디폴트로 기본 타입이 아닌 serializable 자바 클래스 또는 인터페이스의 이름을 가진 Hibernate 타입 serializable을 나타낼 수도 있다. clob, blob java.sql.Clob와 java.sql.Blob JDBC 클래스들에 대한 타입 매핑들. 이들 타입들은 몇몇 어플리케이션들에서는 불편하다. 왜냐하면 blob 또는 clob 객체는 트랜잭션 외부에서 재사용될 수 없기 때문이다.(게다가 드라이버 지원이 비일관적이고 페치되어야 한다) imm_date, imm_time, imm_timestamp, imm_calendar, imm_calendar_date, imm_serializable, imm_binary 대개 가변적인 Java 타입들로 간주되는 것에 대한 타입 매핑들. 여기서 Hibernate는 불변적인 Java 타입들에 대해서만 적절한 어떤 최적화를 행하고, 어플리케이션 그 객체를 변할 수 없는 것으로 취급한다. 예를 들어, 당신은 imm_timestamp로서 매핑된 인스턴스에 대해 Date.setTime()을 호출하지 않을 것이다. 프로퍼티의 값을 변경시키고, 그 변경을 영속화 시키기 위해서, 어플리케이션은 하나의 새로운 (동일하지 않은) 객체를 그 프로퍼티에 할당해야 한다. 엔트리들과 콜렉션들의 유일 식별자들은 binary, blob 그리고 clob를 제외한 기본 타입 중 어느 것일 수 있다. (Composite 식별자들이 또한 허용된다. 아래를 보라.) 기본 value 타입들은 org.hibernate.Hibernate에 정의되어 있는 대응하는 Type 상수들을 갖는다. 예를 들어, Hibernate.STRING은 string 타입을 표현한다. 개발자들이 그들 자신들의 value 타입들을 생성시키는 것이 상대적으로 쉽다. 예를 들어, 당신은 java.lang.BigInteger 타입의 프로퍼티들을 VARCHAR 컬럼들로 영속화 시키고자 원할 수 있다. Hibernate는 이것을 위한 미리 만들어진 타입을 제공하지 않는다. 그러나 맞춤형 타입들은 프로퍼티(또는 콜렉션 요소)를 하나의 테이블 컬럼으로의 매핑하는 것에 제약되지 않는다. 따라서 예를 들어, 당신은 FIRST_NAME, INITIAL, SURNAME 컬럼들로 영속화 되는 java.lang.String 타입의 자바 프로퍼티getName()/ setName()를 가질 수 있다. 맞춤형 타입을 구현하려면, org.hibernate.UserType 또는 org.hibernate.CompositeUserType을 구현하고 그 타입의 전체 수식어가 붙은 클래스명을 사용하여 프로퍼티들을 선언하라. 가능한 종류의 것들을 보려면 org.hibernate.test.DoubleStringType을 체크하라. ]]> 하나의 프로퍼티를 여러 개의 컬럼들로 매핑시키는 <column> 태그의 사용을 주목하라. CompositeUserType, EnhancedUserType, UserCollectionType, 그리고 UserVersionType 인터페이스들은 더 많은 특화된 사용들을 위한 지원을 제공한다. 당신은 매핑 파일 속에 UserType에 대한 파라미터들을 제공할 수도 있다. 이것을 행하기 위해, 당신의 UserType은 org.hibernate.usertype.ParameterizedType 인터페이스를 구현해야 한다. 당신의 맞춤형 타입에 파라미터들을 제공하기 위해, 당신은 당신의 매핑 파일들 속에 <type> 요소를 사용할 수 있다. 0 ]]> UserType은 이제 그것에 전달된 Properties 객체로부터 default로 명명된 파라미터에 대한 값을 검색할 수 있다. 만일 당신이 매우 자주 어떤 UserType을 사용할 경우, 그것은 그것에 대한 더 짧은 이름을 정의하는 것이 유용할 수 있다. <typedef> 요소를 사용하여 이것을 행할 수 있다. Typedef들은 이름을 맞춤형 타입에 할당하고, 또한 만일 그 타입이 파라미터화 된 경우에 디폴트 파라미터 값들의 리스트를 포함할 수도 있다. 0 ]]> ]]> property 매핑 상에 type 파라미터들을 사용함으로써 경우에 맞게 typedef 내에 제공된 파라미터들을 오버라이드 시키는 것이 가능하다. 비록 Hibernate의 풍부한 범위의 미리 만들어진 타입들과 컴포넌트들에 대한 지원이 당신이 가끔 맞춤형 타입을 사용할 필요가 거의 없을 것임을 의미할 지라도, 그럼에도 불구하고 그것은 당신의 어플리케이션에서 자주 발생하는 (엔티티가 아닌) 클래스들에 대해 맞춤형 타입들을 사용하는 좋은 형식으로 간주된다. 예를 들어 MonetaryAmount 클래스는 비록 그것이 컴포넌트로서 쉽게 매핑될 수 있을지라도, CompositeUserType에 대한 좋은 후보이다. 이것에 대한 하나의 동기는 추상화이다. 맞춤형 타입으로, 당신의 매핑 문서들은 화폐 값들을 표현하는 당신의 방법에서 가능한 변경들에 대해 장차 검증될 것이다. 하나의 특정한 영속 클래스에 대해 하나 이상의 매핑을 제공하는 것이 가능하다. 이 경우에 당신은 두 개의 매핑된 엔티티들의 인스턴스들 사이를 명확하게 하기 위해 하나의 엔티티 이름을 지정해야 한다. (디폴트로, 엔티티 이름은 클래스 이름과 동일한 것이다.) Hibernate는 영속 객체들에 대해 작업할 때, 질의들을 작성할 때, 또는 명명된 엔티티에 대한 연관들을 매핑할 때 당신으로 하여금 엔티티 이름을 지정하도록 한다. ... ... ]]> 연관들은 이제 class 대신에 entity-name을 사용하여 어떻게 지정되는지를 주목하라. 당신은 매핑 문서 내에서 테이블 또는 컬럼 이름을 역인용기호(`)들 속에 넣어서 생성된 SQL에서 식별자를 인용부호 처리하도록 Hibernate에게 강제할 수도 있다. Hibernate는 SQL Dialect에 대해 정확한 인용 스타일을 사용할 것이다(대개 이중 인용부호 이지만, SQL Server의 경우에는 모난 괄호들이고 MySQL의 경우에는 역인용부호(`)). ... ]]> XML은 모든 사람들을 위한 것이 아니지만, Hibernate에서 O/R 매핑 메타데이터를 정의하는 몇몇 대안적인 방법들이 존재한다. 많은 Hibernate 사용자들은 XDoclet @hibernate.tags를 사용하여 소스 코드 속에 직접 매핑 정보를 삽입시키는 것을 선호한다. 우리는 이 문서에서 이 접근법을 다루지 않을 것이다. 왜냐하면 그것은 엄격하게는 XDoclet의 부분으로 간주되기 때문이다. 하지만 우리는 XDoclet 매핑들을 가진 Cat 클래스에 관한 다음 예제를 포함한다. XDoclet과 ibernate에 관한 추가 예제들은 Hibernate 웹 사이트를 보라. JDK 5.0은 언어 레벨에서 XDoclet-스타일의 주석들, type-safe와 컴파일 시 체킹을 도입했다. 이 메커니즘은 XDoclet 주석들 보다 더 강력하며 도구들과 IDE들에 의해 더 좋게 지원된다. 예를 들어 IntelliJ IDEA는 JDK 5.0 주석들에 대한 자동-완성 기능과 구문 강조를 지원한다. EJB 명세서의 새로운 개정판(JSR-220)은 엔티티 빈즈에 대한 프라이머리 메타데이터 메커니즘으로서 JDK 5.0 Annotations을 사용한다. Hibernate3는 JSR-220(영속 API)의 EntityManager를 구현하고, 매핑 메타데이터에 대한 지원은 별도의 내려받기로서 Hibernate Annotations 패키지를 통해 이용 가능하다. EJB3 (JSR-220)과 Hibernate3 metadata 양자가 지원된다. 다음은 EJB 엔티티 빈으로서 주석이 붙은 POJO 클래스에 관한 예제이다: orders; // Getter/setter and business methods }]]> JDK 5.0 Annotations(그리고 JSR-220)에 대한 지원은 여전히 작업이 진행 중이고 완성되지 않았음을 노트하라. 상세한 것은 Hibernate Anotations를 참조하라. 산출되는 프로퍼티들은 데이터베이스에 의해 산출되는 그것들의 값들을 갖는 프로퍼티들이다. 전형적으로, Hibernate 어플리케이션들은 데이터베이스가 값들을 생성시켰던 임의의 프로퍼티들을 포함하는 객체들을 갱신시킬 필요가 있었다.하지만 generated로 마크된 프로퍼티들은 어플리케이션으로 하여금 이 책임을 Hibernate에게 위임시키도록 한다. 본질적으로 Hibernate가 산출되는 프로퍼티들을 정의했던 엔티티에 대해 SQL INSERT 또는 UPDATE 명령을 내릴 때마다 바로 직후에 산출되는 값들을 검색하기 위해 하나의 select 명령을 내린다. generated로 마크된 프로퍼티들은 부가적으로 inser 가능하지 않아야 하고 update 불가능해야 한다. 오직 Properties marked as generated must additionally be non-insertable and non-updateable. versions, timestamps, 그리고 단순 프로퍼티들 만이 generated로 마크될 수 있다. Hibernate 매핑 파일들 내에 사용자 스키마를 완전하게 정의하기 위한 능력을 제공하기 위해서, Hibernate의 스키마 방출 도구들과 함께 임의적인 데이터베이스 객체들에 대한 CREATE와 DROP을 허용해준다. 비록 트리거들 또는 내장 프로시저들과 같은 것들을 생성시키고 드롭시키기 이해 특별히 고안되었을지라도 하나의 java.sql.Statement.execute() 메소드를 통해 실행될 수 있는 SQL 명령이 여기서 유효하다(ALTERs, INSERTS, 기타). 보조 데0이터베이스 객체들을 정의하는 두 가지 모드들이 본질적으로 존재한다... 첫 번째 모드는 매핑 파일 바깥에서 CREATE 및 DROP 명령들을 명시적으로 나열하는 것이다: ... CREATE TRIGGER my_trigger ... DROP TRIGGER my_trigger ]]> 두번째 모드는 CREATE 및 DROP 명령들을 생성시키는 방법을 알고 있는 하나의 맞춤 클래스를 제공하는 것이다. 이 맞춤 클래스는 org.hibernate.mapping.AuxiliaryDatabaseObject 인터페이스를 구현해야 한다. ... ]]> 덧붙여 이들 데이터베이스 객체들은 어떤 dialect들이 사용될 때 그것들이 단지 적용될 수 있도록 선택적으로 변동될 수 있다. ... ]]>