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

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

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

예를 들어 ‘주문’ 테이블에 ‘상품수’라는 집계 데이터를 추가한 경우를 생각해봅시다. 데이터를 테이블에 저장하려면 당연히 주문 데이터를 등록할 때 상품 수를 계산해야 합니다. 게다가 주문 내용은 한 번 등록했다고 해서 확정되는 것이 아니며, 일정 기간 안에는 변경될 수 있습니다(주문 취소, 주문 개수 변경 등). 따라서 상품 수도 늘어나거나 줄어들 수 있으며, 주기적으로 ‘주문’ 테이블의 ‘상품수’ 열값을 갱신해야 합니다. 이렇게 데이터를 갱신할 때 발생하는 시스템 부하를 반드시 고려해야 합니다.
--- p.161

하지만 가장 큰 문제는 적절한 배타적 제어(동시성 제어, 락) 메커니즘이 없으면 기능적 오류가 발생할 수 있다는 것입니다. 여러 사용자가 동시에 번호 부여 테이블에 접근해 같은 번호를 발급받게 되면, ‘시군구’ 테이블에 데이터를 삽입할 때 유일성 제약 위반이 발생합니다. 그리고 이렇게 되면, 번호가 건너뛰는 경우도 있습니다. / 이를 방지하려면 한 사용자가 번호 부여 테이블에 접근할 때 테이블을 잠궈서 다른 사용자의 접근을 차단해야 합니다. 이런 동시성 제어를 고려한 프로그램 개발은 복잡할 뿐만 아니라, DBMS마다 트랜잭션 격리 수준이 다르기 때문에, 다른 DBMS으로 전환하기도 어렵습니다. 반면 시퀀스 객체는 이미 이러한 락 메커니즘이 내장되어 있습니다.
이러한 이유로 오토넘버링을 애플리케이션에서 직접 구현하는 것은 추천하지 않습니다.