1. 데이터베이스 설계는 어떻게 진행될까
데이터베이스 설계는 그냥 테이블부터 만드는 작업이 아니다. 보통 다음 순서로 진행된다.
1) 요구사항 분석
사용자가 어떤 데이터를 필요로 하는지 정리하는 단계다.
예:
- 학생 정보가 필요한가
- 수강 정보가 필요한가
- 교수와 지도 관계를 관리해야 하는가
이 단계의 결과물은 요구사항 명세서다.
2) 개념적 설계
요구사항을 바탕으로 데이터를 개념적으로 표현한다.
이때 사용하는 대표적인 도구가 E-R 모델(Entity-Relationship Model) 이다.
결과물은 보통 E-R 다이어그램(ERD) 이다.
3) 논리적 설계
E-R 다이어그램을 실제 DB에서 사용할 수 있는 관계형 스키마로 바꾸는 단계다.
- 개체 → 테이블
- 속성 → 컬럼
- 관계 → 외래키 or 별도 릴레이션
같은 식으로 변환한다.
4) 물리적 설계
실제로 어떻게 저장할지 결정하는 단계다.
예:
- 인덱스 생성 여부
- 파일 구조
- 저장 방식
- 성능 최적화
2. 설계할 때 왜 E-R 모델이 필요할까
처음부터 테이블을 바로 만들면 편해 보이지만,
그렇게 하면 구조가 꼬이기 쉽다.
특히 다음 두 가지 문제가 자주 생긴다.
중복성
같은 정보를 여러 번 저장하는 문제다.
예를 들어 분반마다 course_id, title을 반복 저장하면
같은 과목 제목이 여러 행에 중복 저장된다.
이러면 수정할 때 일부만 바뀌어서 일관성 문제가 생길 수 있다.
불완전성
현재 구조로는 어떤 정보를 표현할 수 없는 문제다.
예를 들어 분반 정보만 있고 과목 자체를 나타내는 테이블이 없다면,
아직 분반이 열리지 않은 새 과목은 DB에 넣을 수 없다.
즉, 어떤 구조는 데이터를 저장할 수는 있어도
현실 세계를 충분히 표현하지 못할 수 있다.
결국 E-R 모델의 역할
E-R 모델은 이런 문제를 줄이기 위해
현실 세계의 개체와 관계를 먼저 정리하게 도와준다.
즉, 테이블 만들기 전에 먼저
- 무엇이 개체인지
- 무엇이 관계인지
- 어떤 속성이 필요한지
- 어떤 제약이 있는지
를 정리하는 과정이라고 보면 된다.
3. E-R 모델의 기본 개념
개체(Entity)
현실 세계에서 구별 가능한 대상이다.
예:
- 학생
- 교수
- 과목
- 학과
즉, 독립적으로 존재를 생각할 수 있는 객체다.
개체 집합(Entity Set)
같은 종류의 개체들을 모아둔 집합이다.
예:
- 모든 학생들의 집합
- 모든 교수들의 집합
ERD에서는 보통 사각형으로 표현한다.
관계(Relationship)
개체들 사이의 연결이다.
예:
- 학생이 과목을 수강한다
- 학생이 교수의 지도를 받는다
- 교수가 학과에 소속된다
즉, 개체끼리 어떤 식으로 연관되는지를 나타낸다.
관계 집합(Relationship Set)
같은 종류의 관계들의 집합이다.
예:
- 모든 지도 관계
- 모든 수강 관계
관계도 단순 연결만 있는 게 아니라
필요하면 속성을 가질 수 있다.
예:
- advisor 관계의 date
- takes 관계의 grade
즉, 관계에도 설명 정보가 붙을 수 있다.
4. E-R 다이어그램 보는 법
E-R 다이어그램은 개체, 관계, 속성을 기호로 표현한 그림이다.
기본 기호
- 사각형: 개체 집합
- 다이아몬드: 관계 집합
- 원: 속성
- 밑줄: 주 키
- 이중선: 전체 참여
- 이중 다이아몬드: 식별 관계
왜 그림으로 그릴까?
ERD는 단순히 예쁘게 그리려고 쓰는 게 아니다.
테이블 만들기 전에 구조를 눈으로 검토할 수 있어서 좋다.
특히
- 빠진 개체는 없는지
- 관계 방향이 맞는지
- 중복 저장이 생기지 않는지
- 약한 개체인지 강한 개체인지
이런 걸 미리 확인할 수 있다.
5. 관계의 세부 요소
관계에도 속성이 있을 수 있다
관계는 단순히 “연결”만 표현하는 게 아니다.
예를 들어 학생과 교수 사이 advisor 관계가 있다고 하면,
“언제 지도교수로 지정되었는가” 같은 정보는
학생 속성도 아니고 교수 속성도 아니라 관계 자체의 속성이다.
예:
- advisor(date)
이런 속성을 설명 속성(descriptive attribute) 라고 생각하면 된다.
역할(Role)
같은 개체 집합이 하나의 관계에 두 번 이상 참여할 때는 역할이 필요하다.
예를 들어 과목과 선수과목 관계를 생각해보자.
- 한 과목이 다른 과목의 선수과목일 수 있음
- 둘 다 같은 course 개체 집합에 속함
이럴 때는
- 현재 과목
- 선수 과목
같이 역할 이름을 구분해줘야 헷갈리지 않는다.
6. 속성의 종류
ER 모델에서는 속성도 여러 종류로 나뉜다.
1) 단순 속성
더 이상 쪼갤 수 없는 속성이다.
예:
- ID
2) 복합 속성
여러 하위 속성으로 나눌 수 있는 속성이다.
예:
- name = {first_name, last_name}
- address = {city, street, zip}
실제 관계형 스키마로 바꿀 때는 보통 쪼개서 저장한다.
3) 단일값 속성
한 개체가 하나의 값만 가지는 속성이다.
예:
- 학생의 학번
4) 다중값 속성
한 개체가 여러 값을 가질 수 있는 속성이다.
예:
- 전화번호
- 이메일
- 자격증
예를 들어 교수 한 명이
- 연구실 번호
- 집 번호
- 개인 번호
를 모두 가질 수 있다면 전화번호는 다중값 속성이다.
관계형 모델로 변환할 때는 보통 별도 릴레이션으로 분리해야 한다.
5) 유도 속성
다른 속성으로부터 계산 가능한 속성이다.
예:
- age = today - birth_date
이건 굳이 DB에 저장하지 않고 필요할 때 계산할 수도 있다.
7. 관계의 차수(Degree)
관계에 몇 개의 개체 집합이 참여하는지에 따라 나뉜다.
이진 관계(Binary)
두 개체 집합이 참여하는 관계다.
예:
- 학생 — 지도교수
- 학생 — 수강과목
대부분의 관계가 여기에 속한다.
삼진 관계(Ternary)
세 개체 집합이 동시에 참여하는 관계다.
예:
- 학생 — 교수 — 프로젝트
이건 단순히 이진 관계 세 개로 쪼개면 의미가 달라질 수 있어서
정말로 세 개가 함께 묶여야 하는 관계라면 ternary 관계로 표현하는 게 더 정확하다.
8. 대응 카디널리티(Mapping Cardinality)
카디널리티는 “몇 대 몇 관계인가”를 나타낸다.
예를 들어 학생과 지도교수 관계를 보자.
- 교수 한 명이 여러 학생을 지도할 수 있다
- 학생은 한 명의 지도교수만 가진다
이건 일대다(1:N) 관계다.
대표적인 카디널리티
- 일대일 (1:1)
- 일대다 (1:N)
- 다대일 (N:1)
- 다대다 (M:N)
예시로 이해하기
advisor 관계에서
- 교수: 지도학생이 없을 수도 있음 → 0..*
- 학생: 지도교수가 반드시 한 명 있어야 함 → 1..1
이렇게 생각할 수 있다.
즉, 카디널리티는 단순히 숫자 문제가 아니라
현실 세계의 규칙을 모델에 반영하는 과정이다.
9. 전체 참여와 부분 참여
이건 카디널리티와 함께 자주 나온다.
전체 참여(Total Participation)
모든 개체가 반드시 어떤 관계에 참여해야 하는 경우다.
ERD에서는 보통 이중선으로 표시한다.
예:
- 모든 학생은 반드시 지도교수가 있어야 한다
부분 참여(Partial Participation)
일부 개체만 관계에 참여해도 되는 경우다.
ERD에서는 보통 단일선으로 표시한다.
예:
- 어떤 교수는 지도학생이 없을 수도 있다
왜 중요한가?
이건 나중에 관계형 스키마로 바꿀 때
외래키가 NULL 가능인지, NOT NULL인지와 연결될 수 있다.
즉,
- 전체 참여 → 보통 반드시 참조 필요
- 부분 참여 → 참조가 없을 수도 있음
10. 키(Key)
개체 집합의 키
각 개체를 고유하게 식별하는 속성이다.
예:
- 학생의 ID
- 교수의 ID
- 학과의 dept_name
관계 집합의 키
관계를 고유하게 식별하는 키다.
이건 관계의 카디널리티에 따라 달라진다.
예를 들어 학생(s)과 교수(i)의 관계라면:
| 다대일 | s_id |
| 일대다 | i_id |
| 일대일 | s_id 또는 i_id |
| 다대다 | (s_id, i_id) |
즉, 어떤 쪽이 여러 번 나타날 수 있는지에 따라 키 구성이 달라진다.
11. 약한 개체 집합(Weak Entity Set)
이 부분은 ER 모델에서 꽤 중요하다.
약한 개체는 자기 자신의 속성만으로는 유일하게 구별할 수 없는 개체다.
즉, 다른 개체에 의존해서만 존재를 구분할 수 있다.
예:
- section(분반)
분반은 보통 course 없이 단독으로 존재한다고 보기 어렵다.
어떤 과목의 분반인지가 있어야 의미가 생긴다.
식별 개체 집합
약한 개체를 식별해주는 강한 개체 집합이다.
예:
- course 가 section의 식별 개체 집합
식별 관계
약한 개체와 식별 개체를 연결하는 관계다.
ERD에서는 이중 다이아몬드로 표시한다.
예:
- sec_course
약한 개체의 키
약한 개체의 주 키는 보통
식별 개체의 키 + 약한 개체의 부분 키(discriminator)
로 구성된다.
예:
section의 경우
- course_id
- sec_id
- semester
- year
이 합쳐져야 분반을 유일하게 식별할 수 있다.
즉:
약한 개체에서 헷갈리기 쉬운 점
ER 다이어그램에서는 약한 개체 안에 식별 개체의 키를 직접 속성처럼 안 그릴 수도 있다.
하지만 실제 관계형 DB로 구현할 때는 반드시 포함해야 한다.
즉,
- 개념 모델에서는 종속성을 강조
- 구현 모델에서는 실제 키 컬럼이 필요
이 차이를 구분해야 한다.
12. E-R 다이어그램을 관계형 스키마로 변환하는 방법
이제 ERD를 실제 테이블 구조로 바꾸는 단계다.
이 부분이 바로 논리적 설계다.
변환은 크게 몇 가지 경우로 나눠 생각하면 편하다.
1) 단순 속성만 가진 강한 개체 집합
가장 간단한 경우다.
ER 개체 하나를 그대로 릴레이션 하나로 만든다.
예:
즉,
- 개체 집합 → 테이블
- 속성 → 컬럼
으로 바로 옮기면 된다.
2) 복합 속성이 있는 강한 개체 집합
복합 속성은 그대로 둘 수 없고
하위 단순 속성으로 분해해서 넣는다.
예:
- name = {first_name, last_name}
그러면 스키마는 이렇게 바뀔 수 있다.
필요하면 prefix를 붙여도 된다.
예:
- name_first
- name_last
3) 다중값 속성 처리
다중값 속성은 별도 릴레이션을 만들어야 한다.
예를 들어 교수 한 명이 여러 전화번호를 가진다면
전화번호를 instructor 테이블 안에 반복 컬럼으로 넣는 건 적절하지 않다.
그래서 보통 이렇게 분리한다.
inst_phone(ID, phone_number)
여기서 inst_phone의 기본키는 보통
가 된다.
즉, 한 교수에게 여러 전화번호를 연결하는 구조다.
4) 약한 개체 집합 변환
약한 개체는 식별 개체의 주 키를 포함해서 릴레이션을 만든다.
예:
여기서 course_id는 식별 개체인 course에서 온 키고,
나머지는 section을 구분하는 속성이다.
5) 관계 집합 표현
다대다 관계
참여하는 개체 집합들의 주 키를 모두 가져와야 한다.
예:
여기서 date는 관계의 설명 속성이다.
다대일 관계
보통 “다” 쪽에 “일” 쪽의 기본키를 외래키로 넣으면 된다.
즉, 굳이 별도 관계 릴레이션을 안 만들어도 되는 경우가 많다.
예:
- 여러 학생이 한 학과에 속한다면
- student 테이블에 dept_name을 넣는 식
13. 스키마 중복 처리
일대다 / 다대일 관계
“다” 쪽이 전체 참여라면
별도 관계 릴레이션을 만들지 않고 “다” 쪽 릴레이션에 “일” 쪽 키를 넣는 방식이 효율적이다.
예:
- 학생은 반드시 한 학과에 속함
- 그러면 student 릴레이션에 dept_name 추가
이렇게 하면 관계 릴레이션을 따로 만들 필요가 없다.
일대일 관계
한쪽 릴레이션에 다른 쪽의 주 키를 넣고 관계 집합 릴레이션을 생략할 수 있다.
다만 어느 쪽에 넣을지는
- 전체 참여 여부
- NULL 허용 여부
- 설계 의도
를 보고 결정하는 게 좋다.
14. E-R 설계에서 자주 생기는 고민
이 부분은 진짜 중요하다.
ER 모델은 “정답 하나”가 아니라 설계 선택의 문제가 많이 나온다.
1) 속성으로 넣을까, 개체로 만들까?
예: 교수 전화번호
선택지는 여러 개다.
- 단일 속성 phone_number
- 다중값 속성 phone_number
- 별도 phone 개체 집합
어떤 구조가 맞는지는 요구사항에 따라 다르다.
예:
- 전화번호 하나만 필요 → 단일 속성
- 여러 개 가능 → 다중값 속성 or 별도 개체
즉, 현실 세계 규칙을 보고 정해야 한다.
2) 관계로 표현할까, 개체로 만들까?
예: 학생과 분반의 수강 관계
단순히 수강 여부만 저장하면 takes 관계로 충분할 수 있다.
하지만 여기에
- 재수강 여부
- 등록 상태
- 결제 상태
- 수강 신청 시간
같은 정보가 많이 붙으면
단순 관계보다는 registration 같은 별도 개체로 분리하는 게 더 자연스러울 수 있다.
3) 이진 관계로 할까, n진 관계로 할까?
세 개 이상의 개체가 하나의 사실을 이루는 경우는
단순한 이진 관계 몇 개보다 n진 관계가 더 정확할 수 있다.
예:
- 부품 — 공급업체 — 프로젝트
- 학생 — 교수 — 프로젝트
이건 셋이 동시에 묶이는 의미가 중요하다.
4) 관계 속성을 어디에 둘까?
일대다 관계에서는 관계의 설명 속성을 “다” 쪽 개체에 옮길 수 있는 경우가 있다.
예:
- advisor 관계의 date
학생이 지도교수를 정확히 한 명만 가진다면
그 날짜를 학생 쪽 속성으로 옮겨도 의미가 유지될 수 있다.
하지만 다대다 관계에서는 이런 이동이 어려운 경우가 많다.
5) n진 관계를 이진 관계로 쪼갤 수 있을까?
가능한 경우도 있지만, 의미가 달라질 수도 있다.
필요하면 새로운 개체 E를 만들고
- E-A
- E-B
- E-C
형태의 이진 관계로 변환할 수 있다.
그리고 원래 관계의 속성은 E에 넣는다.
하지만 이건 단순 변환이 아니라
원래 의미가 유지되는지 꼭 따져봐야 한다.
15. 핵심 요약
이번 장 핵심만 다시 정리하면 이렇다.
- 데이터베이스 설계는 요구사항 분석 → 개념적 설계 → 논리적 설계 → 물리적 설계 순서로 진행된다.
- E-R 모델은 현실 세계의 데이터 구조를 개체와 관계 중심으로 표현하는 도구다.
- 개체, 관계, 속성, 키, 카디널리티, 참여 제약은 ERD의 핵심 요소다.
- 속성은 단순 / 복합 / 단일값 / 다중값 / 유도 속성으로 나눠 이해할 수 있다.
- 약한 개체는 다른 개체에 의존해서 식별되며, 식별 개체의 키를 함께 사용해야 한다.
- ERD를 관계형 스키마로 변환할 때는 개체는 테이블로, 관계는 외래키 또는 별도 릴레이션으로 변환한다.
- 다중값 속성은 별도 릴레이션으로 분리하는 것이 일반적이다.
- 설계에서는 “속성으로 둘지 / 개체로 분리할지 / 관계로 표현할지” 같은 선택이 중요하다.
마무리
6장은 “좋은 테이블 구조를 만들기 위한 사고방식” 을 배우는 장이라고 보면 된다.
지금까지는 이미 만들어진 테이블에 질의하는 느낌이었다면, ER 모델부터는 이제 반대로
- 어떤 개체가 필요한지
- 어떻게 관계를 맺을지
- 어떤 속성을 어디에 둘지
를 먼저 고민하게 된다.