정규화·중복·무결성

같은 주소를 백 번 적으면 어느 주소가 진짜인지 묻게 된다

고객의 현재주소를 주문 행마다 복사해 두면 조회는 편해 보인다. 여기서는 모든 행이 같은 고객의 현재주소를 뜻한다고 가정한다. 주문 당시 배송지는 시점이 다른 별도 사실이므로 고객 현재주소와 함께 바꾸는 대상이 아니다. 그러나 현재주소를 여러 곳에 중복한 채 고객이 이사했을 때 아흔아홉 행만 고치면 같은 현재 사실에 두 값이 생긴다. 아직 주문하지 않은 고객은 저장할 곳이 없고, 마지막 주문을 지우다가 고객 정보까지 잃을 수도 있다. 정규화는 한 사실을 어디에 둘지 정리하고, 무결성은 정리한 규칙이 계속 지켜지는지 보장하는 관점이다.

먼저 되짚기: 테이블·키·관계

테이블은 같은 종류의 사실을 행과 열로 표현하고, 키는 각 행을 식별하거나 다른 테이블의 행을 가리킨다. 관계는 키를 통해 서로 다른 사실이 어떤 의미로 연결되는지 나타낸다. 정규화는 이 구조에서 중복되는 사실과 잘못된 종속을 찾아 나눈다.

정규화

먼저 작은 두 행에서 한 사실이 어디에 속하는지 보자. O1, C17, 서울, 당시배송지 부산과 O2, C17, 서울, 당시배송지 대전을 주문번호·고객번호·고객현재주소·당시배송지 순으로 적었다. 현재주소 서울은 C17이라는 같은 고객의 사실이 두 번 반복되고, 부산/대전은 서로 다른 주문의 당시 사실이다.

분리한 고객 표는 (C17, 서울) 한 행, 주문 표는 (O1,C17,부산), (O2,C17,대전) 두 행이다. 고객번호로 다시 연결하면 두 주문의 현재주소를 모두 찾을 수 있고 주문별 배송지는 보존된다. 이사 때 고객 표의 서울만 인천으로 바꾸면 현재주소 조회가 함께 바뀐다. O1을 지워도 고객의 현재주소는 사라지지 않으며 주문 없는 새 고객도 고객 표에 넣을 수 있다. 이 작은 변화가 아래에서 말하는 수정·삭제·삽입 이상을 줄이는 목적이다.

둘째 정규형의 작은 예도 먼저 읽자. 같은 주문에 상품 A/B 두 줄이 있을 때 (주문번호, 상품번호)가 줄을 식별한다는 가정 아래 주문일은 두 값 전체가 아니라 주문번호만으로 정해진다. 따라서 주문일은 주문 표에 한 번 두고 수량은 각 상품 줄에 둔다. 아래 정식 조건은 이러한 분해를 기본키 하나에만 의존하지 않고 모든 후보키에 대해 검사하는 방법이다.

정규화는 같은 사실의 불필요한 중복과 그로 인한 삽입·수정·삭제 이상을 줄이도록 관계형 테이블을 분해하는 원칙과 절차다. 함수적 종속은 어떤 속성 또는 속성 집합의 값이 같으면 다른 속성값도 같아야 한다는 관계의 제약이다. 모든 허용 데이터 상태에 성립할 업무 규칙으로 확인하며 표본의 우연한 일치만으로 확정하지 않는다. 예를 들어 고객번호가 고객현재주소를 정한다면 고객번호 → 고객현재주소라고 읽는다. 정규화는 속성이 무엇에 종속되는지 살펴 한 테이블에 섞인 서로 다른 사실을 나눈다.

FD는 함수적 종속의 영어 Functional Dependency를 줄인 말이다. 뒤에서 FD라는 표기를 만나도 다른 이론이 아니라 지금 배운 결정 관계를 뜻한다.

첫째 정규형은 정해진 사용 목적에서 한 칸의 값을 더 나눠 다루지 않는 단위로 표현한다. 예컨대 주문 안의 상품별 수량을 따로 검사해야 한다면 상품 목록과 수량 목록을 한 칸씩에 몰아넣지 않고 줄별로 나눈다. 둘째 정규형은 첫째 정규형을 만족하면서, 어느 후보키에도 속하지 않는 속성이 각 후보키 전체에 종속되고 그 일부에만 종속되지 않게 한다. 주문번호와 상품번호로 줄을 구별하는 표에 주문일을 반복했다면 주문일은 그중 주문번호만의 사실이므로 주문으로 분리한다.

셋째 정규형은 첫째 정규형을 전제로, 당연한 자기결정을 제외한 각 종속에서 결정하는 쪽이 슈퍼키이거나 결정되는 속성이 어떤 후보키의 일부인지를 확인한다. 고객번호와 이름을 알면 고객번호를 안다는 당연한 자기결정이지만 고객번호를 알면 현재주소가 정해진다는 업무 근거가 필요한 종속이다. 슈퍼키·후보키의 뜻은 앞의 키 절에서 배웠다. 기본키로 선택한 하나만 보지 않고 모든 후보키를 기준으로 판단한다는 점이 중요하다.

지금은 고객의 현재 사실과 주문의 사실을 다른 표에 두는 다음 사례로 읽으면 된다. 후보키를 빠짐없이 찾고 위 조건을 적용하는 상세 판단은 개념·논리 모델과 정규화: 뜻을 잃지 않고 표를 나눈다 절에서 이어진다. 정규형의 이름을 외우는 것보다 이 값은 정확히 어느 사실의 키에 달려 있는가를 묻는 것이 핵심이다.

다시 연결하기: 정규화에서 무결성으로

정규화는 사실의 소유 위치를 분리해 중복과 갱신이상을 줄인다. 데이터 무결성은 이렇게 정한 값·키·참조·업무 규칙이 실제 저장과 변경에서도 계속 지켜지는지 다룬다.

데이터 무결성

데이터 무결성은 데이터가 정의된 형식, 값의 범위, 식별 규칙과 관계를 계속 만족해 정확하고 일관된 상태를 유지하는 성질이다. 도메인 무결성은 나이·날짜처럼 값의 형식과 범위를, 개체 무결성은 각 행을 유일하게 식별하는 키를, 참조 무결성은 다른 표의 키를 가리키는 외래키가 존재하는 대상만 참조하는지를 다룬다. 여기에 주문금액은 주문항목 합계와 같다 같은 업무 규칙도 포함된다. 무결성은 데이터가 현실과 반드시 같다는 보증은 아니지만, 적어도 선언한 규칙과 모순되지 않게 한다.

값이 양수라는 조건과 값이 있어야 한다는 조건은 다르다

SQL의 NULL은 값이 알려지지 않았거나 없음을 나타내는 표지다. 수량을 아직 입력하지 않았다는 뜻을 숫자 0과 혼동하지 않는다. 빈 문자열처럼 길이가 0인 문자값과도 같은 개념이 아니다.

CHECK 제약은 저장할 행의 값이 주어진 조건식을 어기는지 검사하는 제약이다. NOT NULL 제약은 해당 열에 NULL을 저장하지 못하게 하는 제약이다. 둘을 함께 읽으면 무슨 값이어야 하는가와 값이 반드시 있어야 하는가를 나누어 생각할 수 있다.

아래는 PostgreSQL 18의 동작을 읽기 위한 자체 예다. CHECK(수량 > 0)에서 >는 왼쪽 값이 오른쪽 값보다 큰지를 비교한다. 수량이 NULL이면 양수인지 판단할 수 없어 미정 결과가 된다. 이 제품의 CHECK는 거짓인 경우를 거부하므로 미정만으로는 필수 입력을 강제하지 못한다.

표의 마지막 줄 때문에 필수 수량에는 두 제약을 함께 둔다. 반대로 NOT NULL만으로는 0이나 음수를 막지 못한다. 고객 참조와 주문 전체 합계까지 이 두 제약이 모두 보장한다는 뜻도 아니다. 규칙마다 검사할 범위와 책임을 정해야 한다.

제품별 확인 근거는 PostgreSQL 18 제약 문서의 5.5.1–5.5.2절이며 확인일은 2026-09-05이다. 문서의 예제 표·코드를 옮기지 않았고 독립 사람 검토 전 설명이다.

한 사실의 소유 위치와 제약을 함께 본다

중복된 주문 한 표의 함수적 종속을 확인해 고객·주문·상품·주문항목으로 사실을 분리한다. 분리한 모델에 키·필수값·외래키·범위·업무규칙을 두고 삽입·수정·삭제 때 무결성을 검증한다.

정규화는 구조를 분리하는 단계이고 무결성은 분리한 구조에서 허용되는 상태를 계속 지키는 단계다.

사례: 고객 현재주소를 주문 100건에 복사한 경우

고객 C17의 현재주소가 주문 100건에 반복 저장되어 있고 이사 뒤 99건만 수정했다고 하자. 같은 현재 사실에 두 주소가 남아 수정 이상이 발생한다. 고객현재주소를 고객 테이블 한 곳에 두고 주문은 고객번호를 참조하면 현재주소의 소유 위치가 하나로 줄어든다.

이때 구조만 나눈다고 끝나지 않는다. 고객번호의 유일성·필수값, 주문의 고객 외래키, 수량의 양수 범위와 필수 여부를 제약으로 둔다. 주문 당시 배송지는 현재주소와 다른 시점의 사실이면 별도 속성·이력으로 보존해 이사 때 함께 덮어쓰지 않는다.

주문 한 줄에서 네 종류의 사실을 분리한다

나쁜 한 표는 주문번호 | 고객번호 | 고객주소 | 상품번호 | 상품명 | 수량을 함께 둔다. 고객주소는 고객번호가, 상품명은 상품번호가 결정하는 사실이므로 각 소유 관계로 분리한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

중복된 한 표의 고객번호가 고객 현재주소를, 상품번호가 상품명을 결정한다. 고객·주문·상품·주문항목으로 분리하고 외래키 참조를 잇는다. 이 사례는 주문 안의 같은 상품을 한 줄로 모으며 주문 당시 배송지는 고객 현재주소와 다른 사실로 보존한다.

먼저 각 열이 어떤 키에 의해 결정되는지 표시한다. 이 예의 고객주소는 같은 고객의 현재주소이며 주문 당시 배송지가 아니다. 고객주소는 고객번호의 사실이고, 상품명은 상품번호의 사실이므로 각각 고객과 상품 테이블로 옮긴다. 주문번호로 고객번호를 거쳐 현재주소를 찾을 수 있더라도 현재주소가 주문 자체의 사실로 바뀌는 것은 아니다.

주문과 상품의 여러 대 여러 관계는 주문항목이 연결한다. 이 축약 사례는 한 주문의 같은 상품을 한 줄에 모으는 경우다. 같은 상품을 여러 줄로 구별해야 하면 주문 안의 항목번호처럼 줄의 식별자를 추가해야 하며 개념·논리 모델과 정규화: 뜻을 잃지 않고 표를 나눈다 절에서 그 경우를 이어서 본다. 그다음 고객번호·주문번호·상품번호의 유일성과 필수 여부, 외래키 관계, 수량의 허용 범위를 제약으로 선언한다. 애플리케이션 검사와 데이터베이스 제약을 함께 쓰되, 여러 경로에서 쓰는 핵심 불변 규칙은 저장소 수준에서도 지키게 한다.

구조 원칙·상태 규칙·성능 선택을 분리한다

정규화는 구조의 책임, 무결성은 허용 상태의 책임, 비정규화는 측정된 성능 문제에 대한 예외 설계다. 세 판단을 같은 말로 처리하지 않는다.

정규화와 읽기 성능을 함께 판단한다

비정규화는 정규화를 몰라서 중복을 남기는 일이 아니다. 원천 사실의 소유 위치, 복제 갱신 방식, 허용 지연, 불일치 탐지와 재생성 절차를 정한 의도적 선택이어야 한다. 먼저 올바른 모델과 무결성을 세우고 실제 측정으로 확인된 읽기 문제에만 최적화를 적용한다.

분해만 많이 한다고 좋은 모델은 아니다

의미 있는 한 사실까지 지나치게 잘게 나누면 조회와 변경 이유를 이해하기 어려워진다. 반대로 화면 모양을 그대로 한 표로 저장하면 여러 업무 사실이 섞여 갱신 이상이 생긴다. 정규형은 기계적인 표 개수 경쟁이 아니라 함수적 종속과 업무 의미를 기준으로 적용한다.

무결성 검사를 애플리케이션 한 곳에만 두면 다른 프로그램이나 일괄 작업이 규칙을 우회할 수 있다. 외래키 없이 번호 관례만 믿으면 존재하지 않는 대상을 가리키는 고아 데이터가 생긴다. 제약을 추가하기 전에는 기존 위반 데이터를 찾아 고치고, 한 행을 삭제·변경할 때 관련 행도 함께 바꿀지 막을지와 이력 보존 정책을 명시해야 한다.

자체 10점 문제

정규화와 데이터 무결성의 관계 및 비정규화 판단기준을 설명하시오.

요구어는 설명이다. 함수적 종속과 중복·갱신이상에서 시작해 한 사실의 소유 위치를 분리하고, 키·필수·참조·범위·업무 제약으로 무결성을 유지하는 흐름을 제시한다. 비정규화는 실제 읽기 병목과 동기화 책임이 있을 때의 의도적 선택으로 한정한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 정규화와 함수적 종속
2. 삽입·수정·삭제 이상
3. 사실의 소유 위치 분리
4. 도메인·개체·참조·업무 무결성
5. 비정규화의 조건과 검증 책임

10점 답안 도식

중복 사실의 함수적 종속을 따라 관계를 분해하고, 키·참조·범위·업무 제약으로 무결성을 유지한다. 그 뒤 측정된 읽기 병목에 대해서만 비정규화를 검토한다. 구조를 나눈 단계와 허용 상태를 지키는 단계, 성능 예외를 선택하는 단계를 구분한다.

모범답안 축약본: 한 사실의 소유 위치와 규칙을 정한다

문제: 정규화와 데이터 무결성의 관계 및 비정규화 판단기준을 설명하시오. 정규화는 함수적 종속을 따라 같은 사실의 중복과 삽입·수정·삭제 이상을 줄이는 관계형 설계 원칙이다. 고객번호가 고객현재주소를, 상품번호가 상품명을 결정한다면 주문 한 표에서 고객·상품·주문·주문항목으로 분리한다. 주문 당시 배송지는 다른 시점의 사실이므로 현재주소와 같이 고치지 않는다. 무결성은 값의 형식·범위, 행 식별의 유일성, 외래키 참조와 주문금액 같은 업무 불변조건을 계속 만족하는 성질이다. 정규화된 원천에 키·필수·참조·범위 제약을 두고 애플리케이션과 저장소에서 검증한다. 읽기 병목이 측정된 경우에만 비정규화나 조회용 복제를 선택하며 원천 소유자, 갱신 방식, 허용 지연, 불일치 탐지와 재생성 절차를 명시한다. 표 개수를 늘리는 기계적 분해와 제약 없는 번호 관례가 대표 실패다.

자체 25점 문제

고객 현재주소·주문 배송지·상품 정보를 포함한 주문 데이터의 정규화와 무결성 설계를 제시하고, 읽기 성능 때문에 비정규화할 때의 통제조건을 설명하시오.

요구어는 설계, 설명이다. 어떤 사실이 어느 키에 종속되는지 먼저 고정하고 시점이 다른 사실을 분리한 뒤, 제약과 비정규화 동기화 책임까지 연결한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 업무 사실과 함수적 종속
2. 고객·주문·상품·주문항목 분해
3. 현재주소와 주문시점 배송지 분리
4. 후보키·기본키·외래키
5. NOT NULL·CHECK·참조·업무 제약
6. 삽입·수정·삭제 이상 검증
7. 측정된 읽기 병목과 비정규화
8. 원천·동기화·불일치 탐지·재생성

25점 답안 도식

함수적 종속으로 고객·주문·상품·주문항목을 분리한 그림에 키·참조·범위·업무 제약을 적용해 원천 무결성을 유지한다. 다음 분기는 그 이후의 성능 선택이다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

함수적 종속에 따른 관계 분해와 키·참조·범위·업무 제약으로 원천 무결성을 먼저 지킨다. 읽기 병목이 실측으로 확인될 때만 조회복제/비정규화를 검토하고 동기화·검증·재생성 책임을 둔다. 확인되지 않은 병목을 이유로 중복을 추가하지 않는다.

25점 모범답안

먼저 고객번호 → 고객현재주소, 상품번호 → 상품명처럼 실제 업무에 항상 성립하는 함수적 종속을 확인한다. 고객 현재주소를 주문마다 반복하지 않고 고객 테이블에 두며 주문은 고객번호를 참조한다. 주문 당시 배송지는 현재주소와 시점·의미가 다른 사실이므로 주문 이력으로 별도로 보존한다. 상품과 주문항목도 식별키와 관계를 기준으로 분리한다.

분리한 구조에는 기본·대체키의 유일성, 필수값, 외래키, 수량 범위와 주문금액 같은 업무 불변조건을 둔다. CHECK(수량 > 0)만으로 필수값 조건을 대신하지 않고 필요한 경우 NOT NULL을 함께 적용한다. 삽입·수정·삭제에서 중복 사실·고아참조·부분 갱신이 생기지 않는지 검증한다.

읽기 병목이 실측으로 확인됐을 때만 의도적 비정규화나 조회용 복제를 검토한다. 원천 사실의 소유 위치를 유지하고 복제 갱신 방식, 허용지연, 불일치 탐지, 재생성 절차를 명시한다. 조회가 편하다는 이유만으로 중복을 원천 모델에 남기지 않으며, 설계 선택은 정규화·무결성·성능 비용을 함께 측정해 결정한다.

이 절의 이론 근거와 범위

함수적 종속과 3정규형의 조건은 저자 공개 자료인 Database System Concepts 7판 정규화 강의의 PDF 11·14·25쪽에서 대조했다. 여러 후보키를 기준으로 한 2정규형은 Elmasri·Navathe의 정규화 강의의 PDF 43–47쪽과 대조했다. 정의 확인일은 2026-09-05이며, 주문·주소 사례와 설명은 직접 구성했다. 원문 도식을 옮기지 않았으며 독립 사람 기술검토·권리검토는 아직 완료되지 않았다.

자기교정과 조건 변경

고객 주소가 주문 시점의 배송지로 반드시 보존돼야 한다면? 현재주소 참조만 두지 말고 주문 시점 배송지 스냅숏을 별도 사실로 저장한다.

조회가 느려 고객 이름을 주문에 복제한다면? 원천 소유 위치, 변경 전파, 허용지연, 불일치 탐지와 재생성 절차를 함께 설계한다.

수량 0을 예약취소 상태로 허용한다면? 기존 양수 제약을 그대로 두지 말고 상태와 수량의 조합 규칙을 명시해 CHECK·업무검증을 바꾼다.

30초 정리

1. 정규화는 속성의 종속을 따라 한 사실을 한 곳에 두어 삽입·수정·삭제 이상을 줄인다.
2. 무결성은 값의 범위, 키의 유일성, 참조 관계와 업무 규칙이 계속 지켜지는 성질이다.
3. 비정규화는 측정된 읽기 문제와 명시된 동기화·검증 책임이 있을 때만 선택한다.
4. 좋은 설계는 표의 개수가 아니라 사실의 소유 위치와 규칙이 분명한지를 본다.