1. 데이터 모델링이란
현실 세계의 구조를 DB에
저장 가능한 구조로 표현하는 과정이다.
학교를 예시로 보면
- 현실
학생이 과목을 수강한다 - DB 표현
학생, 과목, 수강(교차 엔터티) 같은 구조로
저장할 수 있게 설계도를 만든다
정리하면
현실 세계의 정보를 약속된 표기법(ERD 등)을
활용해서 데이터베이스 구조로 표현하는 과정
2. 모델링의 기본 원칙과 유의사항: '단추명'
모델링 원칙
- '단'순화: 누구나 이해 가능하게
- '추'상화: 핵심 특징만 간략하게
- '명'확화: 해석이 갈리지 않게
유의사항(유연/유일/일관)
- 유연성
: 요구나 구조가 바뀌어도 쉽게 대응 가능한가 - 유일성
같은 정보를 중복 저장하지 않는가 - 일관성
관계가 명확하고 흔들리지 않는가
(학생-과목 사이에 수강이라는 관계처럼)
3. 데이터 모델링을 보는 3가지 관점
1) 데이터 관점
학생, 과목처럼 데이터 자체를 중심으로 본다
2) 프로세스 관점
학생이 과목을 수강한다 같은 업무 흐름으로 본다
3) 데이터와 프로세스 상관 관점
두 관점을 함께 보고 CRUD로 점검한다
- Create: 수강 신청 등록
- Read: 수강 목록 조회
- Update: 수강 변경
- Delete: 수강 취소
4. 모델링 수행 단계: '개논물'
| 단계 | 핵심 목적 | 결과물 느낌 |
| 개념적 | 현실을 추상화해서 구조 잡기 | ERD로 큰 그림 |
| 논리적 | 테이블 구조로 변환 + 정규화 | PK/FK 포함한 논리 스키마 |
| 물리적 | DB에 실제 구현(타입/인덱스 등) | 실제 CREATE TABLE 수준 |
- '개'념적: 학생/과목/수강을 그림으로 분리한다
- '논'리적: 그림을 테이블로 바꾸고 정규화를 적용한다
- '물'리적: 타입, 길이, 인덱스 같은 구현 디테일을 확정한다
5. 데이터 모델의 필수 구성요소 3가지
- 엔터티: 저장할 대상의 집합
(학생, 과목, 수강) - 속성: 엔터티의 최소 데이터 단위
(학번, 이름, 과목명) - 관계: 엔터티 사이 연관성
(학생-수강-과목)
6. ERD 표기법 메모
- IE 표기법, Barker 표기법이 대표적
- IE: PK를 구분하는 형태로 표현
- Barker: PK에 # 같은 방식으로 표현
7. ERD 작성 순서: '도배설명차선'을 기억하자!
- 엔터티 '도'출
- '배'치 (핵심 엔터티를 왼쪽 상단)
- 관계 '설'정(선으로 연결)
- 관계'명' 기술
- 관계 '차'수 기술(1:1, 1:N, M:N)
- 필수/'선'택 사양 기술
8. 엔터티
엔터티 '개사유'를 기억해라!
- '유'형 엔터티: 학생
- '개'념 엔터티: 과목
- '사'건 엔터티: 수강
'발생 시점 관점'으로 보면
- 기본 엔터티
다른 엔터티에 영향을 받지 않고 독립적으로 존재
(학생, 과목, 고객, 직원 등)
- 중심 엔터티
기본 엔터티와 행위 엔터티를 연결
(수강신청, 주문 등)
- 행위 엔터티
두 개 이상의 엔터티를 상속받아 생성되는 행위
많은 수정사항이 발생한다.
(수강/주문내역 등)
9. 속성
더 이상 분리되지 않는 최소의 데이터 단위(=원자성)
속성의 원자성 예시
나쁜 저장 예) 원자성 X
- 학생A | 수학, 과학
좋은 저장 예) 원자성 O
- 학생A | 수학
- 학생A | 과학
원자성은 결국
- 한 칸에는 하나의 값
- 여러 값이면 행을 늘리거나 별도 테이블로 분리
속성의 특징
- 엔터티는 속성의 집합이다
- 1개의 속성은 1개의 속성 값을 가진다
- 주식별자에 함수적 종속 관계를 가진다
- 업무에서 관리되는 정보다
※ 함수적 종속
A 속성에 의해 B가 유일하게 결정되는 관계 (A → B)
예: 학번 → 이름, 생년월일
학번이 정해지면 이름과 생년월일은
한 사람으로 유일하게 결정된다.
이것을 학번(주식별자)에 나머지 속성들이
함수적 종속 관계를 가진다고 한다.
속성의 명명법
- 업무에 사용하는 명칭을 사용한다
- 서술식 표현은 금지한다
- 약어 사용은 지양한다
- 유일성을 지킨다(중복 금지)
예시)
- 학생이름, 학생생년월일 같은 형태는 가능
- 학생의 이름이다 같은 문장형 표현은 피한다
속성의 분류
속성은 분류 기준이 3가지 축으로 나뉜다.
- 특성에 따른 분류
- 분해 가능 여부에 따른 분류
- 구성방식에 따른 분류
1) 특성에 따른 분류
- 기본 속성: 본래 가지고 있는 속성
(이름, 학번, 고객 ID) - 설계 속성: 필요로 인해 도출된 속성
(주문번호, 일련번호 등) - 파생 속성: 변형되어 만들어진 속성
→ 계산된 값에 해당 (합계, 평균 등)
2) 분해 가능 여부에 따른 분류
- 단일 속성: 하나의 의미로 구성 (이름, 학번)
- 복합 속성: 하위 속성으로 나눌 수 있음
예: 주소 → 시/도, 도로명, 건물번호 - 다중값 속성
여러 값을 가질 수 있어 별도 테이블로 분리 관리
예: 전화번호, 이메일, 취미
3) 구성방식에 따른 분류
- 기본키 속성(PK)
인스턴스를 유일하게 구별하는 속성, 주식별자 - 외래키 속성(FK)
다른 엔터티와의 관계로 연결된 속성
관계를 DB가 이해하도록 만들어주는 연결 도구다
자식 엔터티는 부모 엔터티의
기본키(PK)를 외래키(FK)로 포함한다 - 일반 속성
PK/FK가 아닌 나머지 속성
도메인
도메인은 속성이 가질 수 있는
제한 사항을 정의한 것이다.
데이터 타입과 크기, 허용 가능한 값의
범위를 정해서 데이터 무결성을 보장한다.
예시)
- 성별: 남/여
- 나이: 0~120 사이 정수
- 학번: 8자리 정수형 숫자
10. 관계 구성: '관차선'을 기억하자!
- '관'계명
수강한다 - '차'수
학생 1명은 여러 수강을 가진다(1:N)
과목 1개도 여러 수강을 가진다(1:N) - '선'택사양
필수/선택 참여 여부(표기법에 따라 O 또는 점선 등)
11. 교차 엔터티로 M:N 관계 풀기
관계형 DB에서는 M:N을 직접 구현하기
어려워서 교차 엔터티를 둔다.
학생 ↔ 과목이 원래는 M:N 이지만
- 학생 1 : N 수강
- 과목 1 : N 수강
으로 바꿔서 구현한다.
테이블 형태 예시
STUDENT(student_id PK, name, birth, ...)
SUBJECT(subject_id PK, subject_name, ...)
ENROLL(enroll_id PK, student_id FK, subject_id FK, enroll_date, ...)
예시 데이터
ENROLL
enroll_id | student_id | subject_id | enroll_date
1 | A | MATH | 2026-02-08
2 | A | SCI | 2026-02-0812. ANSI/SPARC 3계층 스키마 구조
스키마는 DB 설계도이며 3계층으로 나뉜다.
- 외부 스키마: 사용자 관점(앱/웹/ATM 등)
- 개념 스키마: 전체 논리 구조(입출금 시스템 자체)
- 내부 스키마: 물리 저장 구조(저장 장치/파일 구조)
독립성 2가지
- 논리적 독립성: 개념 스키마 변경이 외부 스키마에 영향이 없어야 한다
- 물리적 독립성: 내부 스키마 변경이 개념/외부에 영향이 없어야 한다
13. 식별자
논리 모델링에서 인스턴스를 유일하게
구분하는 속성(또는 집합)
식별자의 분류 4가지
식별자는 인스턴스를 유일하게
구분할 수 있는 속성 또는 속성의 집합이다.
식별자는 기준에 따라 4가지 관점으로 분류한다.
1) 대표성 여부에 따른 분류
- 주식별자(기본키, PK)
대표성, 유일성, 최소성, 불변성, 존재성(Not Null)을 만족
- 보조식별자(대체키, AK)
유일하게 구분은 가능하지만 대표성은 없는 식별자
예시)
학번과 주민등록번호가 모두 유일하더라도,
학교 시스템에서 대표 식별자로는 학번을 쓰는 경우
주민등록번호는 유일하지만
학교의 대표성을 만족하지 않는다고 볼 수 있다
2) 스스로 생성 여부에 따른 분류
- 내부식별자
엔터티 내부에서 스스로 생성되는 식별자
- 외부식별자(외래키, FK)
다른 엔터티로부터 받아오는 식별자
예시)
STUDENT 테이블의 student_id는 내부식별자
ENROLL 테이블의 student_id는
STUDENT에서 받아오므로 외부식별자(FK)
3) 속성의 수에 따른 분류
- 단일식별자
하나의 속성으로 구성된 식별자
- 복합식별자
둘 이상의 속성으로 구성된 식별자
→ 이 때문에 속성의 집합이라는 표현이 붙는다
예시)
단일: 학번 하나로 식별
복합: 주문상세에서 주문번호 + 상품번호 조합으로 식별
4) 대체 여부에 따른 분류
- 본질식별자
업무 프로세스 상 현실에 존재하는 식별자
- 인조식별자
인위적으로 생성한 식별자
물리적으로 편하게 관리하기 위해
만드는 경우가 많다 (수강신청번호, 주문번호 등)
예시)
본질: 학번, 주민등록번호처럼 현실에 존재
인조: enroll_id, order_id처럼 시스템이 생성
식별자 관계와 비식별자 관계
부모 엔터티의 식별자를 자식이 어떻게
사용하느냐에 따라 관계를 두 가지로 구분한다.
1) 식별자 관계(강한 연결 관계)
- 부모 엔터티로부터 받은 식별자를
자식 엔터티의 주식별자로 이용한다 - Null이 있으면 안 된다
- 부모와 자식이 같은 생명주기를 가진다
예시)
학생(학번)이 없으면 수강도 존재할 수 없는 구조
> 수강의 PK가 학번을 포함하거나
> 학번 자체가 수강을 식별하는 구성
2) 비식별자 관계(약한 연결 관계)
- 부모 엔터티로부터 받은 식별자를
자식 엔터티의 일반 속성으로 사용한다 - 부모와 자식이 서로 다른 생명주기를 가질 수 있다
예시)
수강은 enroll_id 같은 별도 PK로 식별하고
student_id는 FK로만 들고 있는 구조
> 학생 정보가 삭제되더라도 수강 기록은 남기는
> 정책 같은 경우에 자주 맞는다
※ 추가 정리
식별자 관계는 부모-자식 연결이 의무에 가깝고
비식별자 관계는 부모-자식 연결이 선택 성격을 가질 수 있다
※ 표기 구분
IE 표기법: 점선으로 비식별자 관계를 표현
Barker 표기법: Bar(|) 여부로 비식별자 관계를 파악
14. 키(Key)
물리 모델링에서 제약조건으로 구현되는 키
키의 종류
- 슈퍼키: 유일성 만족, 최소성 부족
- 후보키: 유일성 + 최소성 만족
- 기본키: 후보키 중 대표 키
- 대체키: 기본키를 제외한 후보키
- 외래키: 다른 테이블 기본키 참조
포함 관계
- 슈퍼키 ⊃ 후보키 ⊃ 기본키/대체키
마무리 요약
- 데이터 모델링은 현실을
DB 구조로 옮기는 설계 과정이다 - 원칙은 단순화/추상화/명확화,
유의사항은 유연성/유일성/일관성이다 - 개념-논리-물리(개논물) 순서로
ERD → 테이블 → 실제 구현으로 내려간다 - M:N 관계는 교차 엔터티로 풀어서
1:N + N:1로 구현한다 - 3계층 스키마 구조는 변경이 사용자/서비스에
영향을 주지 않게 독립성을 확보하기 위한 구조다
'개주 훈련일지 > 🎰 SQLD 준비' 카테고리의 다른 글
| SQLD SQL 기본 (0) | 2026.02.15 |
|---|---|
| SQLD 데이터 모델과 SQL (0) | 2026.02.13 |