1:1 관계에서는 외래 키를 어디에 두는지, 그리고 그 외래 키를 PK로 쓸지 여부에 따라 식별/비식별 관계가 갈린다. 예제로 회원과 회원 상세 프로필을 생각해 본다.

5-1. 비식별 1:1 – 대리 키 + FK + UNIQUE

member와 member_profile이 1:1 관계라고 가정한다.

CREATE TABLE member (
  member_id BIGINT NOT NULL AUTO_INCREMENT,
  email     VARCHAR(100) NOT NULL,
  name      VARCHAR(50)  NOT NULL,
  PRIMARY KEY (member_id),
  UNIQUE (email)
);

CREATE TABLE member_profile_non_identifying (
  profile_id BIGINT NOT NULL AUTO_INCREMENT,  -- 독립적인 PK
  member_id  BIGINT NOT NULL,                -- FK
  nickname   VARCHAR(50),
  bio        TEXT,
  PRIMARY KEY (profile_id),
  UNIQUE (member_id),                         -- 1:1 보장
  CONSTRAINT fk_profile_member_non
    FOREIGN KEY (member_id)
    REFERENCES member (member_id)
);

• member_profile는 profile_id라는 자기만의 PK를 가진다.
• 1:1 관계를 보장하기 위해 member_id에 UNIQUE 제약을 건다.
• 관계는 비식별 관계이다.

장점:

• 프로필을 다른 테이블과 별도로 확장하기 쉽다.
• 필요하다면 프로필 구조를 통째로 갈아엎고 새 테이블로 이전해도, member_id FK만 잘 유지하면 된다.
• PK 구조가 단순해서 ORM 매핑이 쉽다.

5-2. 식별 1:1 – PK = FK

이번에는 프로필 테이블의 PK를 곧 member_id로 사용하는 방식이다.

CREATE TABLE member_profile_identifying (
  member_id BIGINT NOT NULL,      -- PK + FK
  nickname  VARCHAR(50),
  bio       TEXT,
  PRIMARY KEY (member_id),
  CONSTRAINT fk_profile_member_iden
    FOREIGN KEY (member_id)
    REFERENCES member (member_id)
);

• 이 구조에서는 프로필의 PK가 member_id 하나뿐이다.
• 회원이 삭제되면 프로필도 같이 사라지는 강한 결합 구조이다.

장점:

• PK만 봐도 "이 프로필은 어느 회원 것인지"가 바로 드러난다.
• 특정 회원의 프로필을 조회할 때 PK = FK이므로 심플한 쿼리를 사용할 수 있다.

단점: