꾸준함

트랜잭션 범위의 영속성 컨텍스트순수 J2SE 환경에서 JPA를 사용하면 개발자가 직접 엔티티 매니저를 생성하고 트랜잭션도 관리해야 하지만스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 컨테이너가 제공하는 전략을 따라야 함 1. 스프링 컨테이너의 기본 전략스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 디폴트로 사용해당 전략은 트랜잭션의 범위와 영속성 컨텍스트의 생존 범위가 같다는 뜻트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근  스프링 프레임워크를 사용하면 보통 비즈니스 로직을 시작하는 서비스 계층에 @Transactional 어노테이션을 선언해서 트랜잭션을 시작함외부에서는 단순히 서비스 ..

본질식별자 vs 인조식별자엔티티는 반드시 데이터를 식별할 수 있는 속성이 존재해야 하며 이를 식별자라고 지칭식별자는 대체 여부에 따라 본질식별자와 인조식별자로 분류 가능본질식별자: 업무에 의해 만들어진 식별자인조식별자: 업무적으로 만들어지지는 않지만 본질식별자가 복잡한 구성을 갖고 있으므로 인위적으로 만든 식별자 가. 본질 식별자  [그림 I-2-21] 주문상품 모델의 식별자가 본질식별자주문상품 모델은 주문 시 구매한 상품 정보를 관리 아래 표는 하나의 주문에 세 개의 상품을 구매한 것을 데이터로 표현했으며 이러한 데이터로 개발을 진행하여 주문상품 모델에 값을 Insert 하는 경우 다음과 같이 SQL로 표현 가능  주문번호상품번호주문수량11000112341110001156651100012342 나. 인..

1. Null 값의 연산은 언제나 Null이다Null 값은 `공백이나 숫자 0`과는 전혀 다른 의미`아직 정의되지 않은 미지의 값` 또는 `현재 데이터를 입력하지 못하는 경우`를 의미즉 Null은 값이 존재하지 않음을 말함 주문번호주문금액주문취소금액1100001100,00020,000110000215,000   위 주문 모델에 들어 있는 데이터를 바탕으로 SQL을 실행하면 다음과 같은 결과를 얻습니다.COL1, COL2, COL3는 최종 주문금액을 구하는 산식최종 주문금액은 각 주문의 주문금액에서 취소된 주문금액을 제외한 결과[표 I-2-8] 결과를 보면 Null 값이 포함되었을 경우 COL1, COL2, 그리고 COL3의 결과가 모두 다르게 출력하는 것을 알 수 있는데 이는 Null 연산은 언제나 Nu..

트랜잭션트랜잭션은 데이터베이스의 논리적 연산단위계좌이체를 통해 트랜잭션을 설명할 수 있음돈을 보내는 사람의 계좌에서 이체금액을 차감하고, 돈을 받는 사람의 계좌에 이체금액을 가산계좌이체라는 업무는 위와 같은 두 가지 단계로 진행되며, 데이터 정합성을 위해 위 작업은 전부 실행되든지 아니면 전부 취소되든지 해야 함즉, 하나의 업무 단위로 묶여서 처리돼야 한다는 것이고 이러한 업무 단위를 트랜잭션이라고 함 부연 설명계좌이체를 하기 위해서는 먼저 A 고객의 잔고에서 이체금액을 차감하고, B 고객의 잔고에 이체금액을 가산해야 함중요한 것은 잔고를 차감하고 가산하는 단계가 모두 완료된 후에 커밋을 수행하는 것잔고 차감/가산 단계가 모두 성공해야지만 커밋이 수행되어 정상적인 데이터를 반영할 수 있음 데이터 모델링의..

1. 조인아래 모델은 고객과 주문 엔티티가 관계를 맺고 있는 모습고객 엔티티의 입장에서는 `한 명의 고객은 여러 번 주문할 수 있음`주문 엔티티 입장에서는 `각각의 주문은 반드시 한 명의 고객에 의해 발생됨`관계를 맺음으로써 생기는 현상은 고객 엔티티의 식별자인 고객번호를 주문 엔티티에 상속시킨 것즉, 관계를 맺는다는 것은 식별자를 상속시키고 해당 식별자를 매핑 키로 활용해 데이터를 결합하여 보겠다는 것 고객번호고객명100정우진101한형식102황영은 주문번호고객번호주문상태코드1100001100주문완료1100002101주문완료1100003101취소요청1100004102환불요청1100005100교환완료 주문 데이터의 [고객] 데이터에서 고객번호를 상속시킨 것을 볼 수 있음주문번호가 1100001인 주문의 고..

1. 제1정규형: 모든 속성은 반드시 하나의 값을 가져야 한다하나의 속성에는 하나의 값을 가져야지만 제1정규형을 만족시킴아래 모델과 같이 연락처 속성에 다중 값(multivalued)이 들어가는 경우 다음과 같은 문제점이 발생할 수 있음연락처 정보에서 집전화 번호와 핸드폰 번호를 구별하기 어려움A 고객은 집전화가 여러 대고, B 고객은 핸드폰인 여러 대라면 혼재된 속성에서 원하는 속성 값을 추출하기 어려움명확하지 않은 속성은 이메일처럼 다른 유형의 데이터를 포함할 수도 있어 본연의 의미가 퇴색될 수 있음데이터를 아래와 같이 관리한다면 개발 복잡성이 증가하고, 연락처 속성에 담긴 본래의 의미가 점차 퇴색될 것 고객번호고객명연락처10000정우진02-123-4567, 010-1234-567810001한형식01..

스프링 데이터 JPA 소개스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트CRUD를 처리하기 위한 공통 인터페이스 제공레포지토리를 개발할 때 엔터피에스만 작성하면 실행 시점에 스프링 데이터 JPA가 구현 객체를 동적으로 생성해서 주입따라서 데이터 접근 계층을 개발할 때 구현 클래스 없이 인터페이스만 작성해도 개발을 완료할 수 있음   부연 설명일반적인 CRUD 메서드는 JpaRepository 인터페이스가 공통으로 제공하므로 문제가 없지만MemberRepository.findByUsername(...)처럼 공통으로 처리할 수 없어 직접 작성한 메서드는 스프링 데이터 JPA가 메서드명을 분석해서 다음 JPQL을 실행SELECT m FROM Member m WHERE username..

객체지향 쿼리 소개EntityManager.find() 메서드를 사용하면 식별자로 엔티티 하나를 조회 가능이렇게 조회한 엔티티에 객체 그래프 탐색을 사용하면 연관된 엔티티들을 찾을 수 있음식별자로 조회: EntityManager.find()객체 그래프 탐색: i.g. member.getTeam() 하지만 이 기능만으로는 애플리케이션을 개발하기 어려움ex) 나이가 30살 이상인 회원을 모두 검색하고 싶을 때 좀 더 현실적이고 복잡한 검색 방법 필요데이터는 DB에 있으므로 SQL로 필요한 내용을 최대한 걸러서 조회해야 하는데 ORM을 사용하면 DB 테이블이 아닌 엔티티 객체를 대상으로 개발하므로 검색도 테이블이 아닌 엔티티 객체를 대상으로 하는 방법이 필요 JPQL은 위와 같은 문제를 해결하기 위해 만들어졌..

문제 링크입니다: https://school.programmers.co.kr/learn/courses/30/lessons/389630 프로그래머스SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.kr 비트마스크를 통해 풀 수 있는 문제였습니다. 알고리즘은 다음과 같습니다.1. 격자의 모든 칸의 visible 값을 더해 기본 점수를 구하고, 각 칸에서 hidden과 visible의 차이를 diff로 계산합니다. 2. 각 행을 뒤집거나 그대로 두는 모든 경우 {2^(행 수}) 가지를 고려하여, 뒤집힌 행의 수에 따른 비용을 기본 점수에서 차감해 기준 점수를 정합니다. 3. 각 열에서 "열을 그대로 둘 때”와 “열을 뒤집을 때..

기본값 타입아래 예제의 Member에서 String, int가 값 타입Member 엔티티는 id라는 식별자 값도 가지고 생명주기도 있지만값 타입인 name, age 속성은 식별자 값도 없고 생명주기도 회원 엔티티에 의존이에 따라 회원 엔티티 인스턴스를 제거하면 name, age 값도 제거됨  임베디드 타입 (복합 값 타입)임베디드 타입은 새로운 값 타입을 직접 정의해서 사용하는 것중요한 것은 직접 정의한 임베디드 타입 또한 int, String처럼 값 타입이라는 것 임베디드 타입 적용 전회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 그리고 주소 우편 번호를 멤버 변수로 가짐  임베디드 타입 적용 후앞선 설명은 단순히 정보를 풀어둔 것뿐근무 시작일과 우편번호는 서로 아무 관련이..