효율적으로 테이블을 설계하고 관리하는 방법
ER 다이어그램
ER 다이어그램 or ERD: 엔티티 관계를 나타내는 그림
📌 ERD의 목적
- 데이터베이스에 저장되는 엔티티의 구조를 모델링하는 것을 목적
- 데이터베이스로 구현할 대상을 시각적으로 설계하는 것
- ERD는 데이터베이스 설계의 초기 단계에서 매우 중요한 역할
📌 ERD를 활용하면 좋은 점
- 데이터베이스 구조를 명확하게 정의할 수 있음
- 향후 데이터베이스를 확장하거나 수정할 때 영향 범위를 쉽게 파악 가능
- 개발자 간의 원활한 소통과 협업에 도움
- 유지보수가 쉬워짐
📌 ERD 없이 무작정 테이블부터 만들면 생기는 문제
- 처음부터 잘못된 구조로 개발을 시작하게 됨. "첫 단추를 잘못 꿰는" 셈
- 시간이 지나면서 유지보수가 어려워지고, 결국 구조 변경에 많은 시간이 소요됨
- 이미 많은 레코드가 쌓여 있다면 수정은 더 복잡하고 부담스러움
- 비효율적인 설계는 데이터의 중복과 불일치를 유발할 수 있음
- 이는 결국 성능 저하로 이어질 수 있음
ERD 표기 방식
📌 피터 첸 표기법
- 엔티티와 관계를 개념적으로 모델링하는 데 유용한 방식
- 그러나 엔티티가 많아지면 다이어그램이 복잡해지고,
이를 RDBMS의 테이블 구조로 해석하기 어려울 수 있다는 단점도 존재
📌 현대 실무형 ERD – IE 표기법
- 현재는 실무에서 RDBMS 모델링을 위해 위와 같은 직관적인 테이블 중심의 ERD가 많이 사용됨
- 이 방식은 IE 표기법(Information Engineering Notation)이라고 불리며,
별명으로 '새발 표기법' 또는 '까마귀 발 표기법'이라고도 불림. 테이블 간 관계를 나타내는 선이 마치 새의 발처럼 생겼기 때문
📌 현대 실무형 ERD – IE 표기법
- 사각형 하나가 테이블 하나를 의미함
- 상단에는 테이블 이름
- 중간 ~ 하단에는 필드 목록(속성)
- 기본키(PK)는 밑줄 또는 'PK'로 표기
- 외래키(FK)는 'FK'로 표기하기도 함
- 필드의 데이터 타입도 함께 명시하는 경우가 많음
피터 첸 표기법: 개념적 설계에 적합
IE 표기법: 실무 설계에 적합
📌 식별/비식별 관계
때로는 ERD에서 엔티티 간의 연결선을 실선과 점선으로 구분하여 표기하기도 함
- 실선: 식별 관계를 의미
- 점선: 비식별 관계를 의미
- 식별 관계
- 참조되는 엔티티가 존재해야만 참조하는 엔티티가 존재할 수 있는 관계
- 참조되는 테이블의 기본 키를 참조하는 테이블의 외래 키이자 기본 키로 활용하는 경우 식별 관계
- 비식별 관계
- 참조되는 엔티티가 존재하지 않아도 참조하는 엔티티가 존재할 수 있는 관계
- 참조되는 테이블의 기본 키를 참조하는 테이블의 기본 키가 아닌 일반적인 외래 키로 이용할 경우 비식별 관계
ERD를 그리기 위한 도구
draw.id / ERWin / ERDCloud 등이 대표적
정규화
데이터 중복과 이상을 방지하기 위해 테이블을 잘 조직하고 필요시 분리하는 과정
- 정규화된 테이블 형태를 정규형(Normal Form, NF)이라고 부름
- 정규화는 단순히 보기 좋게 나누는 게 아니라, 잠재적인 문제(삽입/갱신/삭제 이상)를 예방하기 위한 '규칙'
정규화를 잘 이해하고 활용하면, 유지보수성, 확장성, 성능까지 잡을 수 있음
📌 정규화 이전 테이블 예제
📌 제1 정규형
- 모든 속성이 원자값을 가져야 함
- 하나의 필드에 복수 값이 들어가면 안 됨
- 중복을 감수하고 하나의 테이블로 정리
- 또는, 테이블을 분리하여 정규화
📌 제2 정규형
- 제1 정규형을 만족하면서, 기본키가 아닌 모든 필드가 기본키 전체에 완전히 종속되어야 함
- 특히 기본키가 복합키일 때(2개 이상의 필드로 구성) 주의
- 일부 키에만 종속된 필드가 있다면, 부분 함수 종속성 발생 → 위반
- 부분 함수 종속성: 기본 키가 아닌 필드가 기본 키의 일부에 종속되어 있는 경우
- 완전 함수 종속성: 키본 키 전체에 완전하게 종속되어 있는 경우
즉, 제2 정규형은 부분 함수 종속성이 없는 상태, 후보 키에 속하지 않는 모든 필드가 기본 키에 완전 함수 종속인 상태라고 할 수 있음
이 테이블에서 이름은 학번과의 종속 관계는 있을 수 있지만, 과목과는 관계가 없으므로 제2 정규형을 만족하지 않음
다음과 같이 테이블을 분할해야 제2 정규형을 만족하는 상태가 됨
📌 제3 정규형
- 제2 정규형을 만족하면서, 기본키가 아닌 필드들이 이행적 종속을 가지면 안됨
- 이행적 종속: A → B → C 라면, A → C도 되므로 C는 A에 이행적으로 종속
- 즉, 기본키가 아닌 필드끼리 서로 종속되면 안됨
학번과 학과로 구성된 테이블. 학과와 학과 사무실 위치로 구성된 테이블로 쪼갤 경우 제3 정규형을 만족하게 됨
📌 보이스/코드 정규형(BCNF)
- 제3 정규형을 만족하면서, 모든 결정자가 후보키여야 함
- 결정자: 다른 속성의 값을 결정할 수 있는 속성 (예: A → B에서 A는 결정자)
이 테이블은 이행적 종속 관계에 있는 필드가 없기 때문에 제3 정규형을 만족하지만 BCNF는 만족하지 않음
담당 교수 필드는 키가 아니지만, 과목 코드의 결정자 역할을 하기 때문
따라서 이 경우에는 학번과 과목 코드 필드를 하나의 테이블로, 과목 코드와 담당 교수 필드를 다른 하나의 테이블로 분리해야함
📌 테이블이 정규화 되는 과정
📌 역정규화
정규화를 거듭할수록 데이터는 깔끔하게 분리되고, 이상 현상(중복, 불일치 등)은 줄어듬
하지만 그만큼 테이블 개수가 늘어나고, JOIN 연산이 많아지며, 성능 저하가 발생할 수도 있음
역정규화(De-normalization): 성능 향상을 위해 정규화된 테이블을 다시 통합하거나, 정규화를 일부러 수행하지 않는 것
정규화는 분명 중요한 설계 기법이지만, 항상 정답은 아니며,
상황에 따라 정규화와 역정규화를 적절히 조합하는 것이 실무의 핵심
참고: 북스터디 - 이것이 취업을 위한 컴퓨터 과학이다 (Chapter 6-5)
