데이터베이스 설계, 이렇게 하면 된다

옮긴이 머리말 x
머리말 xii
베타리더 후기 xv

CHAPTER 1 | 데이터베이스를 제압하는 자가 시스템을 제압한다 1
1.1 시스템과 데이터베이스 2
1.2 다양한 데이터베이스 4
1.3 시스템 개발 과정과 설계 10
1.4 설계 단계와 데이터베이스 14

CHAPTER 2 | 논리 설계와 물리 설계 23
2.1 개념 스키마와 논리 설계 24
2.2 내부 스키마와 물리 설계 29
2.3 데이터베이스 단위의 중복 구성: 복제 46
2.4 클라우드에서의 데이터베이스 중복 구성 50
2.5 클라우드 활용 시점과 상황 58
2.6 백업 설계 63
2.7 복구 설계 75

CHAPTER 3 | 논리 설계와 정규화: 왜 테이블을 분할해야 할까? 82
3.1 테이블이란? 82
3.2 테이블의 구성 요소 85
3.3 정규화란 무엇인가? 96
3.4 제1정규형 97
3.5 제2정규형: 부분 함수 종속 104
3.6 제3정규형: 이행적 함수 종속 109
3.7 보이스-코드 정규형(BCNF) 112
3.8 제4정규형 118
3.9 제5정규형 123
3.10 정규화 정리 124

CHAPTER 4 | ER 다이어그램: 여러 테이블의 관계 표현하기 131
4.1 테이블이 너무 많아! 132
4.2 테이블 사이의 관계 파악하기 132
4.3 ER 다이어그램 작성 방법 135
4.4 ‘다대다’ 관계와 관계 엔터티 140

CHAPTER 5 | 논리 설계와 성능: 정규화의 단점과 비정규화 146
5.1 정규화의 장단점 147
5.2 비정규화와 성능 154
5.3 중복성과 성능의 트레이드오프 160

CHAPTER 6 | 데이터베이스와 성능 164
6.1 데이터베이스 성능을 결정하는 요소 165
6.2 인덱스 설계 167
6.3 B-tree 인덱스 설계 방법 173
6.4 통계 정보 180
6.5 인덱스 이외의 튜닝 방법 186

CHAPTER 7 | 논리 설계 안티패턴 198
7.1 논리 설계에서 하지 말아야 하는 것 198
7.2 비스칼라값(제1정규형 미만) 199
7.3 더블 미닝 204
7.4 단일 참조 테이블 207
7.5 테이블 분할 210
7.6 부적절한 키 219
7.7 더블 마스터 221
7.8 좀비 마트와 다단계 마트 224

CHAPTER 8 | 논리 설계의 그레이 노하우 231
8.1 규칙의 경계선에 위치한 설계 231
8.2 대리 키: 기본 키가 잘 작동하지 않을 때 232
8.3 칼럼 기반 테이블 247
8.4 애드혹 집계 키 252
8.5 다단계 뷰 255
8.6 데이터 클렌징의 중요성 258

CHAPTER 9 | 고급 논리 설계: RDB로 트리 구조 다루기 268
9.1 관계형 데이터베이스의 약점 269
9.2 오래되었지만 새로운 해법: 인접 리스트 모델 271
9.3 폐쇄 테이블 모델 279
9.4 어떤 모델을 사용해야 할까? 284

APPENDIX A | 부록: 연습 문제 해답 288
1장 해답 (연습 문제 ➡ 22페이지) 288
2장 해답 (연습 문제 ➡ 81페이지) 293
3장 해답 (연습 문제 ➡ 130페이지) 299
4장 해답 (연습 문제 ➡ 142페이지) 302
5장 해답 (연습 문제 ➡ 162페이지) 304
6장 해답 (연습 문제 ➡ 196페이지) 311
7장 해답 (연습 문제 ➡ 230페이지) 315
8장 해답 (연습 문제 ➡ 264페이지) 316
9장 해답 (연습 문제 ➡ 286페이지) 325

맺음말 327
찾아보기 331

정규화(normalization)는 엔터티(테이블)를 시스템에서 효율적으로 사용할 수 있도록 정리하는 작업입니다. 특히 데이터 등록, 수정, 삭제와 같은 갱신 작업을 일관성 있게 수행할 수 있도록 엔터티 형식을 정리하는 것이 주요 목적입니다. / 단순히 엔터티를 추출하고 속성을 정의하는 것만으로는 실제 시스템에서 활용하기 부족합니다. 따라서 관계형 데이터베이스의 논리 설계에서 정규화는 굉장히 중요한 기초입니다. 정규화는 데이터베이스 논리 설계를 이해하는 핵심이라고 할 수 있습니다.

데이터베이스는 (…) 시스템의 심장과 같습니다. 따라서 데이터베이스 내부의 데이터가 손실되는 일은 절대 없어야 합니다. 만약 그런 일이 발생한다면 엄청난 손해를 감수해야 합니다. 대규모 시스템에서 이러한 데이터 손실 사고가 발생하면 신문이나 TV 등 미디어에서 대대적으로 보도됩니다. / 이러한 ‘사고’를 예방하기 위한 설계에는 두 가지 접근법이 있습니다. 첫째는 최대한 데이터를 잃지 않게 설계하는 것으로, 이전에 설명한 가용성 설계가 여기에 해당합니다. 둘째는 그럼에도 장애로 데이터가 손실되었을 때 복구할 수 있게 준비하는 것입니다. 이 두 번째 접근법이 바로 이번 절과 다음 절에서 다룰 백업과 복구에 관한 내용입니다.

그렇다면 제2정규형이 왜 필요할까요? 제2정규형으로 만들면 어떤 장점이 있을까요? 이런 핵심적인 내용을 이해하지 못한 상태로 정규화 절차만 기계적으로 외우는 엔지니어들도 있습니다. 하지만 이는 본질을 놓치는 태도입니다. 따라서 차근차근 제2정규형의 장점을 제대로 이해해봅시다. (…) 먼저 정규화 이전의 ‘직원’ 테이블(104페이지)을 살펴봅시다. 이 테이블로 실제 업무를 처리하려고 하면 어떤 문제가 생길까요? 예를 들어 직원 정보가 아직 없는 회사(C건설)를 등록하려고 할 때, 기본 키의 일부인 직원ID를 알 수 없는 상태(NULL)이므로 테이블에 등록할 수 없습니다. 물론 직원ID에 임시로 가짜 값을 넣는 방법도 있고, 실제로 그렇게 운영하는 시스템도 있지만 이는 근본적인 해결 방법이 되지 못합니다. 이런 잘못된 방법은 처음부터 피하는 것이 좋습니다.