본문 바로가기

Database

 (14)
ORM(JPA)으로 RDB 관점을 흐리지 않고 개발하는 법 개요ORM은 좋은 도구지만 정해진 용도로만 쓰고 그 선을 넘지 말자! DB는 관계형이지 객체지향이 아니므로, 객체지향적 환상을 DB에 강요하면 안된다."ORM을 쓰되 관계형 DB의 관점을 잃지 말자"는 주장을 JPA와 Spring 환경에 맞춰 정리한 것이다. ORM의 장점과 적절한 사용 범위1. ORM(JPA)이란 무엇이고 무엇이 좋은가?ORM(Object Relational Mapping)은 객체와 관계형 데이터베이스를 연결해 주는 기술이다. DB의 member 테이블과 코드의 Member 클래스를 자동으로 매핑해 주므로, SELECT * FROM member 같은 SQL을 직접 쓰지 않고 객체를 다루듯 DB를 다룰 수 있다.@Entity@Table(name = "member")public class ..
신선식품 자사몰 ERD 설계서 1. 문서 개요개요신선식품 자사몰 + 백오피스 데이터 모델을 정의하고, 각 엔티티와 관계가 어떤 요구사항에서 비롯되었는지 추적 가능하도록 설계 근거를 기재한다. 개발팀이 이 문서만으로 스키마 의도를 이해할수있도록 한다.범위회원/권한, 상품/재고, 장바구니, 주문/결제, 클레임(취소·반품·교환), 쿠폰/포인트, 리뷰/Q&A, 알림신선식품 특화: 유통기한, 보관온도, FEFO(First Expired First Out)도메인 특성신선식품 자사몰은 단일 판매자 자사몰 위에 신선식품 특유의 제약(유통기한, 보관온도, 선입선출 출고, 폐기 관리)이 얹힌 구조다. 일반 커머스와 가장 크게 다른 지점은 "같은 상품이라도 입고 시기마다 유통기한이 다르다"는 점이며, 이것이 재고 모델 설계 전체를 좌우한다.도메인 구성 ..
논리적 모델링 (식별 관계 vs 비식별 관계) 개요현대 데이터베이스 설계의 사실상 표준: 대리 키-PK, 자연 키-UNIQUE, 관계-비식별관계 유형식별 관계비식별 관계(권장)자식 PK부모 PK 포함 복합키독립 대리 키(단일)1:NPK에 의미 있으나 복합키 관리 복잡단순성, 유연성, ORM 친화1:1UNIQUE 없이 1:1 강제, 유연성 낮음FK에 UNIQUE로 1:1 보장, 결합도 낮음M:N복합키가 중복 규칙 강제, 확장성 심각히 낮음대리 키 + FK조합 UNIQUE = 정합성+유연성관계 변경PK 수정 필요 → 무결성 붕괴 위험FK 값/제약만 변경계층 확장PK 전파로 비대화단일 FK 하나만 추가ORM@IdClass/@EmbeddedId 등 번거로움단일 @Id로 자연스러움1. 식별과 비식별 관계 개념지금까지 외래 키(FK)로 테이블 간 관계를 맺어왔..
논리적 모델링 (다대다 관계) 개요3대 제약(PK 유일, FK 단일참조, 컬럼 원자성) 때문에 두 테이블만으론 표현 불가연결 테이블로 M:N을 1:N + N:1로 분해해서 양쪽 PK를 FK로 갖고 JOIN으로 양방향 조회실무의 M:N은 대부분 관계 속성(수량, 당시 가격 등)을 가져서, 연결 테이블은 order_item처럼 의미 있는 연관 엔티티가 되고, 개념적 모델링 단계에서 이미 별도 엔티티로 식별되는 경우가 많다.1. 두 테이블만으로는 M:N을 표현할 수 없다관계형 DB의 기본제약 다대다(M:N) 관계를 표현할수 없다.관계형 DB의 기본제약관계형 DB의 3개의 기본제약에 의해 테이블의 행은 다음 특징을 가진다.PK 유일FK는 단일 행만 참조컬럼은 원자적(1NF)두 테이블간 다대다 관계 시도예) 주문과 상품의 다대다 관계: 주문1..
논리적 모델링 (일대일 관계) 개요테이블을 분리하는 것보다 합치는 게 나을 때가 많아 드물지만, 성능, 보안, 선택적 정보, 관심사 분리를 위해 분리한다.FK 위치는 보조 테이블에 두는 것이 표준(확장성, OCP, 1:N 전환 용이)1:1 강제하기 위해 FK + UNIQUE 사용, UNIQUE가 없으면 1:N으로 새어버린다.예외적으로 주 테이블 FK를 두는것은 관계가 필수라 정합성을 DB로 강제하거나, JOIN을 피해야 할 만큼 조회 성능이 중요하거나, ORM 편의가 우선일 때만1. 왜 굳이 1:1로 분리하나?하나의 행이 다른 테이블의 단 하나의 행과만 관계를 맺는 경우이다. 1:1 관계는 사실 하나의 테이블로 합치는 게 더 효율적인 경우가 많아서 상대적으로 드물다. 그럼에도 분리하는 전략적 이유는 네 가지이다.케이스 이유 예시케이스..
논리적 모델링 (참여도와 일대다 관계) 개요개념적 모델링의 추상적인 관계선이, 논리적 모델링에서는 외래 키(Foreign Key) 라는 구체적 형태로 구현된다. FK를 어디에 두느냐가 데이터 모델의 유연성과 확장성을 결정관계형 DB의 관계는 방향이 없고, FK 하나로 양방향 조회가 된다.관계의 두 축은 카디널리티(몇 개 연결?)와 참여도(필수/선택?)참여도는 FK 컬럼의 NULL / NOT NULL로 구현FK가 있는 쪽(N) 참여도는 NULL 제약으로 간단히 제어 가능FK가 없는 쪽(1)의 필수 참여는 DB 제약으로 강제 불가하여 애플리케이션 계층에서 처리 (DB로 못 막아도 ERD에는 원래 비즈니스 규칙을 반드시 표현)일대다 관계의 FK는 반드시 "다(N)" 쪽에 둔다. (PK 유일, FK 단일참조, 컬럼 원자성을 모두 만족하는 유일한 방법..
논리적 모델링 (키) 개요대리 키-PK, 자연 키-UNIQUE, 관계-비식별키설명기본 키(PK)대표 키이며, NOT NULL + UNIQUE + 불변후보 키PK 자격(유일성 + 최소성)을 만족하는 키대체 키후보 키 중 PK로 안 뽑힌 나머지외래 키(FK)다른 테이블의 PK를 참조해 관계 연결복합키두 개 이상 컬럼을 묶은 키자연 키: 의미 있는 비즈니스 데이터(주민번호·이메일)를 PK로 직관적이지만 '변경 가능성' 이 치명적 약점이어서, PK로 사용시 참조 무결성 위반, 연쇄 업데이트, 역사성 훼손, 외부 연동 마비 발생대리 키: 비즈니스와 무관한 자동 생성 값(AUTO_INCREMENT)이므로 절대 불변해서 비즈니스가 바뀌어도 데이터 구조 안정성능: 자연 키는 JOIN 회피로 단순 조회에 유리할 수 있으나 FK 비대화와 단편..
개념적 모델링 개념적 모델링이란?곧바로 CREATE TABLE을 하지 않고 그림부터 그리는 이유는, 데이터베이스가 결국 현실 세계 비즈니스를 반영하는 거울이기 때문이다. 어떤 테이블, 컬럼이 필요한지는 "어떤 비즈니스를 할 것인가"에 달려 있다.개발자, 기획자, 현업 담당자가 모두 모여 합의하는 과정기술 용어 대신 모두가 이해할 수 있는 그림과 용어로 소통특정 기술(관계형 DB, NoSQL 등)에 종속되지 않음1. 엔티티 도출요구사항 분석 후 Entity 도출 과정시스템이 정보를 저장하고 관리해야 할 대상을 엔티티로 도출물리적인 형태가 있는 명사(고객, 상품 등)를 찾아 기본 엔티티 후보로 삼는다.물리적인 형태는 없지만 업무적으로 관리해야 할 중요한 개념(상품 카테고리, 회원등급)을 찾아 기본 엔티티 후보로 삼는다.기..

티스토리툴바