바로 직전 포스팅에서는 단방향 매핑에 대해서 살펴보았다. 단방향으로 매핑해주었기 때문에 한쪽에서 반대 방향으로 (예시의 경우 Member -> Team) 호출할 수 있었지만, 그 반대로는 불가능했다. 양방향 매핑으로 바꿔서 양쪽으로 참조가 될 수 있도록 해보겠다. Mapping 우선, 사실 테이블의 연관관계에서는 외래 키를 통해서 조인이 되기 때문에 방향성이라는 개념이 존재하지 않는다. 그렇기 때문에 테이블 연관관계의 형태를 살펴보면 단방향 매핑과 달라진 것이 없는 것을 알 수 있다. 반대로 객체의 경우에는 양방향으로 연관관계를 맺어주기 위해서는 별도의 매핑 작업이 필요하다. 이번에는 Team의 입장에서 생각해보아야 한다. Team의 입장에서는 다수의 Member가 소속될 수 있기 때문에 Member와는..
객체의 참조와 테이블의 외래 키를 매핑하는 방법에 대해서 알아보자. Base 가령, 다음과 같은 요구사항이 있다고 가정해보자. 1. 회원과 팀이 있다. 2. 회원은 하나의 팀에만 소속될 수 있다. 3. 회원과 팀은 다대일 관계다. 관계형 DB의 경우에서 위 예시를 매핑하기 위해서는 아래와 같이 MEMBER 테이블에서는 외래 키를 가지고 있어야 한다. 그래서 이러한 구조를 그대로 객체로 옮겨오게 되면 Member Entity에는 teamId를 가지고 있어야 하는데, 이것은 객체지향적인 설계에 어긋난다. 코드로 풀어서 살펴보면, // 회원을 저장하는 경우 (외래키 식별자를 직접 다룸) Team team = new Team(); team.setName("TeamA"); em.persist(team); Memb..
이번에는 Annotation과 속성을 중점으로 Entity를 매핑하는 방법에 대해 살펴본다. 데이터 베이스 스키마 자동 생성 JPA는 Appplication 로딩 시점에 DB 생성 기능을 지원한다. 개발시 테이블을 만들어 두고 객체를 넣어두는 방식이 아닌 객체 매핑을 해두면 알아서 필요한 테이블을 생성해준다. 설정은 아래와 같이 persistence.xml에 추가해주면 된다. " ??? " 부분에 들어갈 옵션은 총 5개로 아래와 같다. create : 기존 테이블 삭제 후 다시 생성 (먼저 DROP후 CREATE) create-drop : create와 동일하지만 종료 시점에 DROP update : 변경분만 반영 (ALTER), 추가만 가능하고 지우는 건 적용되지 않음. validate : 엔티티와 테..
영속성? JPA에서의 영속성 이란, Entity를 영구 저장하는 어떤 환경을 뜻한다. 이전 포스팅에서 살펴봤던 EntityManager.persist(entity) 라는 것은 DB에 저장한다는 것이 아니라, 영속성 컨텍스트를 통해서 Entity를 영속화하는 것. 즉, Entity를 영속성 컨텍스트에 저장하는 것이다. 영속성 컨텍스트는 논리적인 개념이고, EntityManager를 통해서 영속성 컨텍스트에 접근할 수 있다. 일반적으로 EntityManager를 생성하면 영속성 컨텍스트라는 어떤 공간이 생겨난다. (1:1 관계) 영속성의 생명주기 비영속 (transient) Entity를 생성한 상태 (객체만 생성한 상태) 영속 (managed) Entitymanger 안에 있는 영속성 컨텍스트를 통해서 E..
1. 의존성 및 JPA 설정 기본적으로 H2 DB를 설정한 뒤에 Project에 dependency를 설정해주어야 하는데, 이때 하이버네이트 버전은 내가 사용하고자 하는 SpringBoot가 지원하는 버전을 사용하도록 한다. ( 여기에서 Reference Doc. 에서 확인할 수 있다. ) 그런 뒤에 아래처럼 의존성을 주입해준다. org.hibernate hibernate-entitymanager 5.4.29.Final com.h2database h2 1.4.200 그다음으로 JPA를 띄우기 위하여 JPA 설정이 필요한데 resources 폴더 아래에 META-INF/persistence.xml 파일을 생성하고 아래와 같이 설정 파일을 작성해 준다. 주석 처리해 둔 필수 속성에 DB접근 정보를 넣어주어야..
SQL 중심적인 개발의 문제점 관계형 DB를 사용하는 상황에서는 SQL에 의존적인 개발을 피하기 어렵다. SQL의 객체화 / 객체의 SQL화, 반복적인 SQL 작성은 개발을 힘들게 한다. 관계형 DB가 등장한 배경과 객체지향이 등장한 배경 자체가 틀리다. 관계형 DB는 데이터를 잘 정교화해서 보관하는 것이 목표인 반면, 객체지향은 추상화, 캡슐화등을 통한 복잡성을 제어하기 위함이다. 개발을 진행함에 있어서 객체를 영구 보관하기 위해서는 여러 방법이 있지만, 결국 관계형 DB에 저장하는 것이 최선의 방법이다. 그렇다면 결국 객체를 SQL로 변환해야 하는 것일까? 개발자가 계속해서 SQL Mapper의 역할만 해야 하는 것일까? 또, 객체와 RDB의 차이를 보면, 상속, 연관관계, 데이터 타입 그리고 데이터..