02. 논리 설계: 클래스 다이어그램 (Logic Design)

"코드를 짜기 전, 우리 시스템의 주인공들과 그들의 연결 고리를 정의합니다."

0. 왜 '관계(Relationship)'가 중요한가요?

지난 장에서 데이터베이스가 '거대한 엑셀'임을 배웠다면, 이제는 그 이름 앞에 붙은 '관계형(Relational)'이라는 수식어에 주목할 때입니다. RDBMS의 진정한 힘은 데이터를 쪼개고 연결하는 설계 능력에서 나옵니다.

1) 관계가 없을 때의 비극: 중복과의 전쟁

관계를 설정하지 않고 하나의 표에 모든 정보를 넣으면 데이터 중복(Redundancy)과 이상 현상(Anomalies)이 발생합니다.

저장 공간 낭비: 학생 한 명이 10개의 강의를 들으면, 이름과 전화번호도 10번 저장해야 합니다.
수정의 지옥: 학생의 번호가 바뀌면 10군데를 찾아 모두 고쳐야 합니다. 하나라도 놓치면 데이터의 일관성이 깨집니다.

2) 우리의 목표: 진실은 오직 하나 (Single Source of Truth)

RDB의 핵심은 "어떤 정보든 딱 한 곳에만 존재하게 만드는 것"입니다.

해결: 학생 정보는 Student 테이블에 딱 한 번만 기록합니다.
효과: Enrollment 테이블에서 학생 ID(FK)로 참조만 하면, 원본 데이터가 바뀌어도 연결된 모든 기록이 자동으로 최신 상태를 유지합니다. (무결성 확보)

0-1. [상식] 데이터베이스 용어 정리 (RDB vs NoSQL)

개발자라면 같은 개념을 두고도 다르게 부르는 두 세계의 용어 차이를 알아야 합니다.

개념	RDBMS (MySQL)	NoSQL (MongoDB)	비유
창고	Database (Schema)	Database	엑셀 파일 (`.xlsx`)
표	Table	Collection	엑셀 시트 (Sheet)
행 (데이터)	Row (Record)	Document	한 줄의 정보 (철수)
열 (속성)	Column	Field	항목 이름 (나이, 이름)

💡 [Tip] 관계를 결정하는 질문: '누가 누구를 아는가?'

"강의(Course)는 담당 강사(Teacher)를 알아야 할까?" → Yes. 이 '마음'이 코딩에서는 객체 참조, DB에서는 외래키(FK)가 됩니다.

1. 객체 추출: 수강 신청 시스템의 주인공들

시스템을 구성하는 핵심 객체를 정의하는 것부터 설계가 시작됩니다.

객체 (Object)	설명	주요 속성 (Attributes)
Student	수업을 듣는 학생	`id`, `name`, `email`, `grade`
Teacher	수업을 담당하는 강사	`id`, `name`, `subject`
Course	개설된 강의	`id`, `title`, `capacity`

2. Visible Thinking: 관계의 종류 (Relationship Types)

현실의 관계를 클래스와 ERD로 표현하는 세 가지 대표적인 방식입니다.

1) 1:1 (일대일) : "나와 내 주민등록증"

한 명의 사용자는 오직 하나의 상세 프로필만 가질 수 있는 경우입니다.

2) 1:N (일대다) : "부모와 자식들"

가장 흔한 관계로, 한 명의 유저가 여러 개의 글을 쓰는 구조입니다.

규칙: 외래키(FK)는 항상 'N(다)' 쪽에 위치합니다. (글이 "내 주인은 누구인가?"라는 번호표를 들고 있음)

3) N:M (다대다) : "학생과 강의"

한 학생이 여러 강의를 듣고, 한 강의에 여러 학생이 참여합니다.

규칙: RDB는 N:M을 직접 연결할 수 없어, 중간에 연결 테이블(Mapping Table)을 두어 1:N 두 개로 풀어냅니다.

3. 실전 적용: 수강 신청 시스템 설계

Step 1. 논리 설계 (Class Diagram)

객체의 데이터(속성)뿐만 아니라 행동(Method)까지 정의하여 시스템의 전체 로직을 시각화합니다. 가장 먼저 AI에게 시스템의 요구사항을 설명하고 설계를 요청해봅시다.

Prompt

수강 신청 시스템을 만들려고 해.

학생(Student)은 이름, 이메일, 학년 정보가 있어.
강사(Teacher)는 이름과 담당 과목이 있어.
강의(Course)는 제목, 정원, 담당 강사가 있어.
학생은 여러 강의를 수강할 수 있고, 강의는 여러 학생을 받을 수 있어 (N:M).

이 관계를 Mermaid classDiagram으로 그려줘.

결과 확인:

classDiagram
    class Student {
        +int id
        +string name
        +string email
        +enroll(course)
    }
    class Teacher {
        +int id
        +string name
        +createCourse()
    }
    class Course {
        +int id
        +string title
        +int capacity
        +addStudent(student)
    }
    class Enrollment {
        +int id
        +int student_id
        +int course_id
        +date enrolled_at
    }

    Teacher "1" --> "*" Course : teaches
    Student "1" --> "*" Enrollment : has
    Course "1" --> "*" Enrollment : has

Step 2. 데이터 설계 (ERD)

논리 설계에서 동작(Method)을 제거하고, 실제 DB 테이블에 들어갈 컬럼과 제약조건 위주로 변환합니다. 이 과정도 AI에게 변환을 요청하면 쉽습니다.

Prompt

위에서 만든 Class Diagram을 바탕으로, ERD(Entity Relationship Diagram)를 그려줘.

Class의 속성(Attribute)을 DB의 컬럼(Column)으로 변환해줘.
N:M 관계가 있다면 반드시 연결 테이블(Mapping Table)을 만들어서 1:N 관계로 풀어줘.
각 테이블의 PK(기본키)를 정해주고, 관계를 맺는 컬럼에는 FK(외래키)를 표시해줘.

결과 확인:

erDiagram
    STUDENT ||--o{ ENROLLMENT : "Enrolls"
    COURSE ||--o{ ENROLLMENT : "Has"
    TEACHER ||--o{ COURSE : "Teaches"

    STUDENT {
        int id PK
        string name
        string email
    }
    TEACHER {
        int id PK
        string name
        string subject
    }
    COURSE {
        int id PK
        string title
        int teacher_id FK
    }
    ENROLLMENT {
        int id PK
        int student_id FK
        int course_id FK
        date enrolled_at
    }

핵심 정리 * 클래스 다이어그램: 시스템의 논리적 구조와 동작을 설계합니다. * ERD: 실제 데이터 저장 구조를 설계하며, N:M 관계는 연결 테이블로 해결합니다. * 무결성과 효율성: 관계 설계의 목적은 데이터 중복을 막고 한 곳에서만 관리하기 위함입니다.

다음 장에서는 이 설계도를 바탕으로 MySQL Workbench에서 실제 '물리 테이블'을 생성해 보겠습니다! 🚀