데이터 모델링에 대한 요약 정리

데이터 모델링이란.

반응형

 

상황(현실 업무)

학교에서 학생이 과목을 수강신청하고, 정원이 차면 막고, 성적도 관리하는 시스템을 만든다고 해봅시다.

---

1) 데이터 모델링이란?

현실을 DB로 옮기기 위해 무엇을 저장할지를 정리하는 겁니다.

• 현실: “홍길동이 데이터베이스 과목을 신청했다”
• 모델링:
  • 학생(학번, 이름)
  • 과목(과목코드, 과목명, 정원)
  • 수강신청(학번, 과목코드, 신청일)

즉, 현실의 문장을 DB에 저장 가능한 구조로 바꾸는 작업입니다.

---

2) 데이터 모델링이 해주는 일(기능) 

• 가시화(그림으로 보이게): “학생–과목–신청” 관계를 ERD로 그리면 한눈에 이해됨
• 명확화: “학생은 학번으로 구분”, “과목은 과목코드로 구분”처럼 기준이 명확해짐
• 구조 제공: 테이블을 어떻게 만들지(학생/과목/신청) 틀이 잡힘
• 문서화/소통: 개발자, 담당자, 교수(업무 담당)가 같은 그림/표를 보고 이야기 가능
• 상세 조절: 초반에는 큰 구조만, 나중에는 인덱스/성능까지 상세 설계 가능

---

3) 왜 중요하고, 무엇을 조심해야 하나?

중요(이유)

• “수강신청” 시스템의 핵심은 결국 누가 어떤 과목을 신청했는지 데이터를 정확히 관리하는 것
• 데이터 설계가 틀리면 기능도 다 꼬입니다.

주의(유의점)

• 중복 저장 금지
  • 나쁜 예: 학생 테이블에도 “신청과목”을 저장하고, 신청 테이블에도 저장 → 꼬임
  • 좋은 예: 신청 정보는 신청 테이블 한 곳에만 저장
• 유연성 확보
  • 과목명이 바뀌어도 신청 기록은 그대로 유지되어야 함 → 구조를 분리해둬야 안전

---

4) 데이터 모델링 3단계(수강신청으로 딱 이해)

① 개념적 모델링(큰 그림, 초반)

“무엇이 존재하는가?”

• 학생, 과목, 수강신청(또는 수강)

② 논리적 모델링(구조를 정확히)

“PK, 관계를 정확히”

• 학생(학번 PK)
• 과목(과목코드 PK)
• 수강신청(학번 FK, 과목코드 FK, 신청일)
• 관계: 학생 1명은 여러 과목 신청 가능(1:N), 과목 1개는 여러 학생이 신청 가능(1:N)
  → 그래서 중간에 수강신청 테이블이 필요합니다(M:N 해결)

③ 물리적 모델링(실제 DB 구현)

“실제 테이블로 만들고 성능까지”

• 신청 테이블에 (학번, 과목코드) 인덱스를 걸어 조회 빠르게
• 정원 체크를 위해 과목 테이블에 정원/현재신청자수 컬럼을 둘지 결정

---

5) 프로젝트 생명주기에서 어디서 하냐? (예시)

• 분석 단계: 학생/과목/신청이 뭔지 정의(개념/논리)
• 설계 단계: 실제 DB 테이블/인덱스/제약조건 설계(물리)

---

6) 데이터 독립성(3단계 스키마) – 예시로

외부 스키마(사용자 화면)

학생 화면: “내 수강신청 목록”
교수 화면: “내 과목 신청자 목록”
→ 화면마다 보이는 형태가 다름

개념 스키마(통합 논리 구조)

학교 전체 기준으로는
학생/과목/신청 구조는 하나로 통합되어 있음

내부 스키마(실제 저장 방식)

DB에서는 인덱스, 저장 구조, 파티셔닝 같은 물리 구조로 저장됨

👉 화면이 바뀌어도(외부) DB 저장 구조가 크게 안 흔들리게 하려고 이렇게 나눕니다.

---

7) 데이터 모델의 핵심 3요소(예시)

• 엔티티(Thing): 학생, 과목, 수강신청
• 속성(Attribute): 학생이름, 학번 / 과목명, 정원 / 신청일
• 관계(Relationship): 학생은 과목을 신청한다

---

8) ERD는 뭐냐? (수강신청 ERD 느낌)

• 학생(1) ─── (N) 수강신청 (N) ─── (1) 과목
  이 그림 하나로 “중간 테이블이 왜 필요한지”가 바로 보입니다.

---

9) 좋은 데이터 모델(예시로 체크)

• 필요한 데이터 다 있음(완전성): 학생/과목/신청 빠짐 없음
• 중복 없음(중복 배제): 신청은 신청 테이블에만
• 규칙 반영: “정원 초과면 신청 불가” 같은 규칙을 제약조건/로직으로 반영
• 소통 도구: 이 ERD/표를 기준으로 개발자와 업무 담당이 같은 말 함