Database,껍데기 제거

관계는 같은 속성 집합을 가진 튜플의 집합이며 후보 키와 함수 종속성이 의미를 제한한다. SQL table은 중복과 NULL을 허용할 수 있으므로 수학적 관계와 완전히 같지 않다. primary key는 선택된 후보 키이고 foreign key는 참조 무결성을 표현한다.

• 오해: ORM model이 곧 관계형 모델이다.
• 실체: 모델의 핵심은 저장 모양이 아니라 참인 상태의 집합이다.

집합, predicate, 논리곱과 SQL의 기본 DDL/DML을 알고 시작한다. marketplace에서 주문번호, 판매자 SKU, 결제사 거래 ID 중 무엇이 후보 키인지 말로 먼저 적는다.

0–3분에는 엔터티와 불변식을 적고, 3–7분에는 키와 종속성을 찾고, 7–11분에는 3NF schema를 만들고, 11–15분에는 위반 INSERT와 NULL predicate를 실행한다.

PostgreSQL은 UNIQUE/PRIMARY KEY를 unique B-tree로 뒷받침하고, foreign key를 trigger로 검사하며, CHECK는 행이 삽입·변경될 때 평가한다. CHECK 결과가 TRUE 또는 UNKNOWN이면 통과하므로 NULL 허용 여부는 NOT NULL로 별도 표현해야 한다.

결제의 자연 후보 키는 provider와 provider_ref의 조합이다. 금액은 통화 최소 단위 정수로 저장하고 양수 불변식을 DB에 둔다.

CREATE TABLE payment (
  payment_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id bigint NOT NULL REFERENCES orders(order_id),
  provider text NOT NULL,
  provider_ref text NOT NULL,
  amount_minor bigint NOT NULL CHECK (amount_minor > 0),
  currency char(3) NOT NULL,
  UNIQUE (provider, provider_ref)
);

반복 그룹을 order_item으로 분리하고 product 사실과 주문 당시 가격 snapshot을 구분한다. 정규화는 갱신 이상을 줄인다. 보고 성능을 위한 비정규화는 원본과 재생성 절차, 일관성 지연을 함께 문서화할 때만 도입한다.

PRIMARY/UNIQUE/FK는 의미 제약이며 동시에 일부 접근 경로를 만든다. PostgreSQL은 foreign key의 참조하는 열에 index를 자동 생성하지 않는다. 조인 plan이 느리다면 의미 모델과 물리 index를 별도로 검토한다.

EXPLAIN SELECT o.order_id
FROM orders o JOIN payment p USING (order_id)
WHERE p.provider = 'stripe' AND p.provider_ref = 'pi_demo';

INSERT는 heap tuple을 만들고 관련 index와 constraint를 갱신한다. 같은 transaction 안의 FK 검사는 기본적으로 statement 끝에 완료되며 DEFERRABLE로 선언한 제약은 transaction 끝까지 미룰 수 있다. 실패하면 transaction 전체가 abort 상태가 된다.

CHECK를 application validation으로만 옮긴 분기를 만들고 두 세션이 음수 결제와 없는 주문 참조를 쓰게 한다. `discount = NULL`과 `discount IS NULL` 결과도 비교한다. 실패가 재현되지 않으면 이 실습은 통과가 아니다.

정상 주문 graph가 commit되는지, 중복 provider_ref·음수 금액·orphan item이 SQLSTATE와 함께 거부되는지, ON DELETE 정책이 의도대로 동작하는지 transaction test로 확인한다.

키 폭은 모든 참조 index와 join 비용에 전파된다. surrogate key를 쓰더라도 자연 후보 키의 UNIQUE를 버리지 않는다. 비정규화의 읽기 절감과 write fan-out, 재구축 시간, 추가 저장량을 함께 측정한다.

tenant_id를 데이터 불변식과 권한 경계 양쪽에 포함하고 composite FK로 교차 tenant 참조를 막는다. 숨겨야 할 값에 NULL을 쓰는 것은 접근 제어가 아니다.

constraint 이름과 SQLSTATE를 관찰 가능하게 남기고 위반률을 배포 회귀 신호로 본다. NOT VALID 제약은 검증 상태를 운영 항목으로 추적한다.

산출물은 ERD, 불변식 표, 후보 키·함수 종속성 목록, 실행 가능한 schema와 위반 fixture다.

각 불변식의 DB 표현 또는 의도적 application-only 사유가 있고, 모든 constraint 실패 test가 통과하며, NULL의 UNKNOWN 사례를 설명할 때 완료다.

답을 보기 전 설명하라: 후보 키와 primary key는 왜 다르며, `CHECK (amount > 0)`만으로 NULL을 막을 수 없는 이유는 무엇인가?