Whiteship's Note


The paradigm mismatch

Hibernate/study : 2007.02.16 15:48


Hibernate를 공부하는 중인데요. 객체와 Relation간의 어떤 차이들이 있는 것인지 궁금해서 살짝 공부해 봤습니다.

The problem of graularity
=> 알갱의 크기가 달라서 생기는 문제

The problem of subtypes
=> 객체의 상속을 Relation에서 표현하기 위한 문제

The problem of identity
=> 객체와 그에 해당하는 row를 식별하는 문제

Problems relating to associations
=> 객체에서의 reference 연관과 Relation의 외례키를 사용한 연관의 차이

The problem of data navigation
=> DB의 성능을 높이기 위한 join과 persistence 객체의 fetching으로 인한 n+1 slelect 문제

'Hibernate > study' 카테고리의 다른 글

하이버네이트의 update() 와 merge()  (2) 2008.04.29
하이버네이트를 쓰려면 게터 세터가 꼭 필요하다.  (0) 2007.12.26
잘못 된 openSession() 사용 예제ㅋ  (0) 2007.05.04
Convention over Configuration  (0) 2007.03.02
숙제 3  (4) 2007.03.01
The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
top

Write a comment.


The problem of data navigation

Hibernate/study : 2007.02.16 15:04


참조 : Java Persistence With Hibernate

객체에서는 . 을 사용해서 다른 객체로 이동하곤 합니다. 하지만 SQL db에서 데이타를 이런식으로 가져오는 것은 효율적이지 않습니다.

db의 성능을 높이는 방법으로 SQL 쿼리 숫자를 줄이는 겁니다. 그래서 연관된 table 간의 join을 이용해서 data를 가져 옵니다.

만약에 Member에 있는 데이타만 관심이 있다면 Select * From member; 이렇게 하면 되겠지만 Member와 Messenger의 데이터에 모두 관심이 있다면 outter join을 이용해서 member를 가져와 두면 나중에 messenger의 데이터를 위해 쿼리를 날릴 필요가 없습니다.

하지만 Object persistence의 경우 객체에 처음 접근 할 때 fetching이라는 기능으로 연관된 객체를 붙여오는 기능을 제공하는데 이것은 각 노드 또는 콜렉션 마다 하나의 쿼리문을 실행하도록 요구하기 때문에 비효율적일 수 있습니다. 이것을 바로 무서운 n+1 selects problem 이라고 한다는 군요.

이 문제에 관해서는 13, 14, 15장에서 Hibernate가 제공해 주는 효율적이면서도 투명한 fetching 기능을 공부할 수 있을 것 같습니다.

'Hibernate > study' 카테고리의 다른 글

하이버네이트를 쓰려면 게터 세터가 꼭 필요하다.  (0) 2007.12.26
잘못 된 openSession() 사용 예제ㅋ  (0) 2007.05.04
Convention over Configuration  (0) 2007.03.02
숙제 3  (4) 2007.03.01
The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
Custom Tag 만들기  (0) 2007.02.07
top

Write a comment.


Problems relating to associations

Hibernate/study : 2007.02.16 13:17


참조 : Java Persistence With Hibernate

객체에서는 객체들의 관계를 reference를 사용해서 나타내지만 관계형 DB에서는 외례키로 나타내기 때문에[footnote]이밖에 데이타 무결성을 위해서도 사용된다.[/foonote] 발생하는 문제입니다.

방향성에 대한 차이
  • Object Reference는 고유의 방향성이 있다. 참조 하는 쪽과 참조 되는 쪽이 있다는 말인듯 합니다. 따라서 양방향성을 설정 하려면 두 번 설정해 줘야 합니다.
public class Member{
    private Set<Messenger> messengers;
}

public class Messenger{
    private Member member;
}
  • Foreign key를 사용한 관계는 정해진 방향성이 없다. 임의로 join이나 projection을 사용해서 연관을 맺을 수 있기 때문에 Navigation이 관계형 데이타 모델에 의미가 없다.

관계에 있어서 차이
  • Java에서는 다 : 다 관계를 표현할 수 있다. Java class를 보고 어떤 관계인지 알 수가 없다.
  • DB에서는 항상 1 : 다 또는 1 : 1 관계다. 외례키 정의한 부분을 보면 어떤 관계인지 알 수 있다.

'Hibernate > study' 카테고리의 다른 글

잘못 된 openSession() 사용 예제ㅋ  (0) 2007.05.04
Convention over Configuration  (0) 2007.03.02
숙제 3  (4) 2007.03.01
The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
Custom Tag 만들기  (0) 2007.02.07
책을 샀습니다.  (0) 2007.02.04
top

Write a comment.


The problem of identity

Hibernate/study : 2007.02.16 12:27


참조 : Java Persistence With Hibernate

Java에는 두 가지의 동일성에 대한 표현[각주:1]이 있고 DB에서의 row에 대한 identity는 주키로 나타내기 때문에 발생하는 문제 입니다.[각주:2]

9.2.2에 보시면 equals()와 hashCode()를 구현할 때 주의할 것들이 나옵니다.
  • equals()와 hashCode()를 테이블의 주키 값의 동일성으로 구현을 하면 transient 객체의 동일성 비교를 할 때 아직 id가 없는 상태이기 때문에 문제가 발생하며..
  • equlas()와 hashCode()를 테이블의 주키를 제외한 다른 모든 속성들의 값으로 구현을 하면 같은 row인데 속성하나가 바꼈다고 다른 row로 인식하거나.. 다른 row인데 값이 같다고 해서 같은 객체로 인식하는 문제가 발생합니다.
  • 그래서 business key를 사용하라는 내용이 있었습니다. 주키는 surrogate key를 사용하는데 둘다 유일한 값을 가지며 차이가 있다면 business key는 어떤 의미가 있는 값(ex. 학번, 주민번호)이 지만 surrogate key는 아무런 의미가 없이 DB에서 식별자 역할 만 한다는 겁니다.
주키를 정할 때 surrogate key로 정하는데 DB를에 row 식별을 위해 만든 속성을 domain model에 표현을 해야하는 건지..? 라는 질문을 던지고 있습니다. 여기에 대해서는 p162쪽 4.2.2에 보시면 Hibernate는 db identity를 application에서 두 가지 방법으로 표현할 수 있다고 합니다.
  • persistence 객체의 식별자 속성의 값으로
  • Session.getIdentifier(Object entity)의 리턴값으로
  1. Equality를 나타내는 equals()와 Object identity를 나타내는 == 이 있습니다. [본문으로]
  2. 단순히 동일성 표현 방법의 갯수가 차이 나서 그런 것은 아닙니다. [본문으로]

'Hibernate > study' 카테고리의 다른 글

Convention over Configuration  (0) 2007.03.02
숙제 3  (4) 2007.03.01
The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
Custom Tag 만들기  (0) 2007.02.07
책을 샀습니다.  (0) 2007.02.04
DisplayTag1.1 예제 보기  (0) 2007.01.30
top

Write a comment.


The problem of subtypes

Hibernate/study : 2007.02.14 20:58


참조 : Java Persistence with Hibernate

객체에서는 상속이라는 것이 있는데 DB에는 그런게 없기 때문에 발생하는 문제입니다.

객체는 클래스라는 타입이 있고 이러한 타입이 상속되는 반면에 DB에 있는 Table은 type이 아니기 때문에 supertable 이나 subtable 같은 단어는 없습니다. 5장 5.1 "Mapping class inheritance"(p192)에서 이 문제에 대한 해결 방법이 나와 있습니다.

사용자 삽입 이미지

만약에 위와 같은 상속 구조를 DB로 표현하는 방법으로 책에서는 네가지 방법(크게 세가지)을 소개하고 있습니다.

1. Table per concrete class(with implicit polymorphism)

사용자 삽입 이미지
상속의 특징 중에 상위 클래스의 속성을 물려 받는 특징은 살렸지만... 다형성은 이용하지 못하겠습니다. 또한 상위 클래스의 속성이 변하게 되면 이런 테이블들 또한 일일히 변하게 되어야 하기 때문에 난감할 수 있겠습니다.

다형성이 필요없고 상위 클래스의 변동이 거의 없는 경우에 사용할 수 있겠습니다.

2. Table per concrete class(with unions)

사용자 삽입 이미지
매핑을 1번과는 조금 다른 방법으로 하지만 테이블의 구조는 1번과 거의 같은 구조의 스키마를 보이게 됩니다. 상위 클래스에 있는 속성들을 중복해서 선언하지 않고 <union-subclass> 태그를 이용해서 매핑 시킬 수 있습니다. 이 때 테이블의 주키도 역시 공유가 되기 때문에 같게 됩니다. 그리고 다형성을 이용할 수 있습니다.

3. Table per class hierarachy

사용자 삽입 이미지
가장 단순하고 성능도 좋은 매핑 전략입니다. 아예 하나의 테이블 안에 넣어 뒀기 때문에 다형성을 사용할 수 있으며 표현하기도 간단합니다.

그런데 하위 클래스들의 속성들은 전부 nullable이어야 한다는 제약이 있습니다. 생각해보면 당연합니다. Employee에 대한 정보를 넣고 싶은데 PartTimeWorker에 대한 정보가 없다고 못 넣는 다는 건.. 좀.....그렇쵸. 그리고 WORKER_TYPE 과 같은 구분자가 필요한데요. 이건 객체에 표시하진 않고 DB에서만 사용됩니다.

그리고 주키 아닌 속성에 종속되는 컬럼 들이 있기 때문에 정규화를 만족시키지 못한다는 것 역시 단점입니다.

4. Table per subclass

사용자 삽입 이미지

상속을 외례키를 사용한 관계로로 표현하는 방법입니다. 3번의 정규화 문제가 해결 됐다는 것이 장점이고 다형성은 join을 사용해서 가능합니다. 구분자도 필요없게 되었습니다. 하지만 맵핑 설정하는 것이 조금 복잡하네요. ~.~ 그리고 복잡한 상속 구조에서의 성능이 굉장히 안좋은 것 같습니다.

이 들 여러 전략들 중에 어느것을 사용할 지는 그때 그때 다르겠지만 3번과 4번이 가장 자주 사용될 듯 한 기분입니다.

'Hibernate > study' 카테고리의 다른 글

숙제 3  (4) 2007.03.01
The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
Custom Tag 만들기  (0) 2007.02.07
책을 샀습니다.  (0) 2007.02.04
DisplayTag1.1 예제 보기  (0) 2007.01.30
DisplayTag 써보기  (2) 2007.01.30
top

Write a comment.


The problem of graularity

Hibernate/study : 2007.02.14 16:06


참조 : Java Persistence With Hibernate

객체는 덩어리의 사이즈가 다양하고 DB에는 덩어리라고 할 수 있는 것이 테이블과 레코드밖에 없기 때문에 생기는 불일치를 말합니다.

덩어리 사이즈에 대한 이해가 쉽지 않았습니다. 예전에 corse-grained와 fine-grained에 대해서 OpenSeed 온라인 강좌에 댓글로 질문을 올렸었는데요. 그 때 승택님께서 답변을 해주셨지만 사실..그땐 잘 이해를 못했었습니다. 지금 다시 보니까 이해가 되는 것 같습니다.

사용자 삽입 이미지

그림에 보이듯이 User는 알갱이가 크다고 합니다. 반면에 Address는 알갱이가 작다고 합니다. 좀 더 자세히 살펴 보자면 다음과 같이 그릴 수 있겠네요.

사용자 삽입 이미지

저기 있는 것들을 단순하게 객체의 속성은 필드로 클래스는 테이블로 매칭시키기에는..뭔가 안맞는 것 같은 느낌이 드는데요. 이걸 해결하는 방법은 p177쪽 부터 설명이 나옵니다.

component라는 것을 사용한다고 하는데요. DDD quickly에서 보았던 Value Object가 나옵니다. 즉 identity를 가질 필요가 없고 값으로써 존재가치가 있는 개체 같은데요. 위에서 Address나 name이 그런 경우에 해당하지 않을까 생각해 봅니다. Account는 고유한 객체를 식별할 필요가 있게 느껴져서요.

'Hibernate > study' 카테고리의 다른 글

The paradigm mismatch  (0) 2007.02.16
The problem of data navigation  (0) 2007.02.16
Problems relating to associations  (0) 2007.02.16
The problem of identity  (0) 2007.02.16
The problem of subtypes  (0) 2007.02.14
The problem of graularity  (0) 2007.02.14
Custom Tag 만들기  (0) 2007.02.07
책을 샀습니다.  (0) 2007.02.04
DisplayTag1.1 예제 보기  (0) 2007.01.30
DisplayTag 써보기  (2) 2007.01.30
Criteria에서 Join하기  (0) 2007.01.29
top

Write a comment.