1. 상속관계 매핑 - 관계형 DB는 상속관계가 없음 - 슈퍼타입 / 서브타입 관계의 모델링 기법이 객체의 상속과 유사 - 상속관계 매핑: 객체의 상속과 구조와 DB의 슈퍼타입 / 서브타입 관계를 매핑 슈퍼타입 / 서브타입 논리 모델을 물리 모델로 구현하는 방법 1. @Inheritance(strategy=InheritanceType.XXX) - 각각 테이블로 변환 => 조인 전략 (JOINED) - 통합 테이블로 변환 => 단일 테이블 전략 (SINGLE_TABLE) - 서브타입 테이블로 변환 => 구현 클래스마다 테이블 전략 (TABLE_PER_CLASS) 2. @DiscriminatorColumn(name=“DTYPE”) 3. @DiscriminatorValue(“XXX”) 조인 전략 - 장점: 테..

ex1. 객체를 테이블에 맞추어 모델링 // (참조 대신에 외래키를 그대로 사용) @Entity public class Member { @Id @GeneratedValue private Long id; @Column(name = "USERNAME") private String name; @Column(name = "TEAM_ID") private Long teamId; ... } @Entity public class Team { @Id @GeneratedValue private Long id; private String name; ... } // (외래 키 식별자를 직접 다룸) //팀 저장 Team team = new Team(); team.setName("TeamA"); em.persist(team);..

- 객체와 테이블 매핑: @Entity, @Table - 필드와 컬럼 매핑: @Column - 기본 키 매핑: @Id - 연관관계 매핑: @ManyToOne, @JoinColumn, ... 1. @Entity - @Entity가 붙은 클래스는 jpa가 관리하고, 엔티티라 부른다. - jpa를 사용해서 테이블과 매핑할 클래스는 @Entity 필수 주의점 1. 기본 생성자 필수( 파라미터가 없는 public 또는 protected 생성자 ) 2. final 클래스, enum, interface, inner 클래스는 사용하지 않는다 3. 저장할 필드에 final 사용하지 않는다. 속성 1. name: jpa에서 사용할 엔티티 이름을 지정하며, 기본값으로 클래스 이름을 그대로 사용하고, 중복된 이름의 클래스가 ..

1. 영속성 컨텍스트 (PersistenceContext) - jpa를 이해하는데 가장 중요한 용어 - 엔티티를 영구 저장하는 환경 - 'EntitiyManger.persist(entity);'를 통해 생성 - 영속성 컨텍스트는 논리적인 개념이다 (눈에 보이지 않으며, 엔티티매니저(필자 약칭 EM)을 통해서 접근) - J2EE, 스프링 프레임워크와 같은 컨테이너 환경에서는 EM과 영속성 컨텍스트가 다대일 관계 2. 엔티티 생명주기 엔티티의 생명주기는 4가지로 분류된다 - 비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 - 영속(managed): 영속성 컨텍스트에 관리되는 상태 - 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태 - 삭제(remove..

Numeric types(숫자형 타입) - 숫자를 나타내기 위해서 사용되는 데이터 타입 - 정수형 타입과 실수형 타입으로 나뉨 A. 정수형 타입 - TINYINT: 최소 -128 ~ 최대 127 까지의 정수를 저장할 수 있는 타입 (TINYINT SIGNED : -128 ~ 127 / TINYINT UNSIGNED : 0 ~ 255) - SMALLINT: TINYINT 보다 좀더 큰 범위의 정수 (SMALLINT SIGNED : -32768 ~ 32767 / SMALLINT UNSIGNED : 0 ~ 65535) - MEDIUMINT: MEDIUMINT SIGNED : -8388608 ~ 8388607 / MEDIUMINT UNSIGNED : 0 ~ 16777215 - INT: INT SIGNED : -..

- 인덱스: 원하는 조건의 row를 더 빠르게 찾기 위해(이진 탐색 이용) 특정 column 값을 정렬해서 저장해 놓은 것 clustered index: 테이블 자체를 특정 순서로 저장하는 인덱스 - 조회 속도가 빠름 - 인덱스를 하나밖에 못 만듬 - 언어 사전과 비슷한 개념 (ex: 영어사전의 인덱스는 영어로 되어있음, 한글은 일일히 찾아야 함) non-clusetered index: 테이블 자체는 그대로 놔두고 다른 곳에 순서를 저장 - 실제 테이블과 무관하게 저장하기 때문에 갯수 제한이 없음 > 인덱스를 모든 컬럼에 대해서 만들 수 있다 - clusteres index보다는 느림 - 책의 색인, 또는 인덱스랑 비슷합니다. 책 내용은 그대로 유지하면서, 따로 개념들을 정렬해놔서, 언제든지 원하는 개념..

정규화 - DB의 테이블이 잘 만들어졌는지 평가하고, 잘 만들지 못한 테이블을 고쳐나가는 과정 - 테이블을 정규형(NF, normal form)이라고 불리는 형태에 부합하게 만들어감 - 일반적으로 3NF에 부합하는 데이터베이스를 보고 "정규화된 데이터베이스"라고 부름 - 제 n정규형 등으로 부르며, 순서에 따라 규칙이 누적됨 - 대부분의 경우 제 3정규형에 부합하기만 하면 잘 정규화된 DB라고 표현 - 정규화를 하면 DB에서 삽입/업데이트/삭제 이상을 제거할 수 있다 - 새로운 종류의 데이터를 추가할 때 테이블 구조 수정을 많이 하지 않아도 된다 - DB구조의 단순화 > 사용자가 더 쉽게 이해 가능 - 데이터 모델을 만들고 실제 DB에 구현하기 전에 적용하면 좋음 (DB 수정이 번거롭기 때문) 1. 제 ..

- git reset 은 Head가 가리키는 브랜치가 가리키는 커밋을 변경함 - git reset --hard 커밋id1: working directory의 내용이 커밋id1 때까지로 변경됨 - history를 보면 커밋id1 때까지의 커밋이 보이고, 파일도 그 커밋에 알맞게 변경됨 - But, hard 작업을 해도 커밋 자체가 삭제되지는 않음, reset 커밋id2(id1 이후의 커밋) 해도 정상적으로 작동 (최신커밋으로 되돌아갈 때는 그 최신커밋의 id를 알고 있어야 함) >> Head가 가리키는 브랜치가 새로운 커밋을 가리키게 됨 1. reflog - 최신 커밋의 id를 모를 때는 git reflog를 사용해서 확인 가능 - git reset --hard abad 와 git reset --hard ..