강한 개체 변환 시 고려사항

ER 강한 개체 → 테이블 확정

컬럼만 옮기지 말고, 4가지 설계 결정을 순서대로 굳힙니다

강한 개체는 바로 테이블이 되지만, 실제 스키마가 되려면 대표 키, NULL 허용, 값 제약, 이름 규칙까지 함께 정해야 합니다.

1단계

PK 전략 선택

2단계

필수값 여부 판정

3단계

도메인 제약 추가

4단계

네이밍 규칙 통일

단계

무엇을 정하나

판단 기준

테이블에 남는 결과

1 PK

개체를 대표할 키를 고른다

자연키, 대리키, 복합키 중 하나를 확정

학번·주민번호처럼 이미 안정적인 값이면 자연키,
실무 편의가 중요하면 대리키, 두 속성이 함께 식별하면 복합키

PRIMARY KEY(student_no)
또는 id BIGINT PRIMARY KEY

2 NULL

필수 속성과 선택 속성을 가른다

ER 모델의 참여 제약을 SQL NULL 규칙으로 변환

반드시 있어야 하는 값은 NOT NULL,
없어도 되는 값은 NULL 허용

name NOT NULL
memo NULL

3 제약

허용 가능한 값의 범위와 유일성을 고정한다

잘못된 값과 중복 입력을 미리 차단

가격·수량처럼 범위가 있으면 CHECK,
후보키나 이메일처럼 겹치면 안 되면 UNIQUE

CHECK (price >= 0)
CHECK (stock >= 0)
email UNIQUE

4 이름

테이블명과 컬럼명을 일관되게 맞춘다

협업과 유지보수에서 읽기 쉬운 스키마로 정리

개체명은 복수형 테이블명으로 두고,
속성명은 snake_case로 통일

students
created_at, order_date