1. 이상현상
정규화란, 릴레이션이 연관된 속성만을 갖도록 분리시키는 것을 말합니다. 이 정규화 작업의 필요성을 알기 위해서는 먼저, 이상현상에 대해 알아둘 필요가 있습니다. 이상현상은 릴레이션이 잘못 설계되어, 불필요한 중복 데이터가 존재할 때 발생하는 현상입니다. 대표적으로 삽입 이상, 갱신 이상, 삭제 이상이 있습니다. 이러한 이상현상을 해결하는 방법이 정규화입니다.
1) 삽입 이상
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
111 | T1 | 오영일 | 2025-01-17 | VIP |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
111 | T3 | 오영일 | 2025-01-17 | VIP |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
111 | T5 | 오영일 | 2025-01-20 | VIP |
다음과 같이, 고객과 거래 정보를 함께 저장하는 릴레이션이 존재한다고 가정하겠습니다. 또한, 각 튜플을 구별할 수 있도록 기본키는 고객 ID와 거래 ID로 구성됩니다. 따라서 둘 중 하나라도 NULL이어선 안되며, 겹치는 조합이 발생해선 안됩니다. 이 고객-거래 릴레이션은 고객 정보와 거래 정보를 함께 갖고 있기 때문에 한 고객이 여러 거래를 했을 경우, 중복된 데이터가 저장됩니다.
만약, 이 때 새로운 고객이 회원가입을 할 경우, 해당 릴레이션에 어떻게 데이터를 저장할 수 있을까요? 고객-거래 릴레이션은 고객과 거래 정보를 함께 저장해야 하므로, 신규 고객이 특정 거래를 하지 않았다면, 임시로 데이터를 넣어야 할 것입니다. 왜냐하면, 기본키인 고객 ID과 거래 ID가 NULL이어선 안되기 때문입니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
111 | T1 | 오영일 | 2025-01-17 | VIP |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
111 | T3 | 오영일 | 2025-01-17 | VIP |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
111 | T5 | 오영일 | 2025-01-20 | VIP |
112 | TEST | 김남규 | 9999-99-99 | BRONZE |
이처럼 신규 고객의 데이터를 저장하기 위해 거래 관련 데이터를 테스트용 데이터로 추가해야만 합니다. 데이터를 저장하기 위해 불필요한 데이터까지 함께 저장해야 하는 이상현상을 삽입 이상이라고 합니다. 이는 릴레이션이 제대로 분리되지 않았을 때, 발생할 수 있습니다.
2) 갱신 이상
만약, 고객의 등급이 변경된다면, 고객-거래 릴레이션에서는 데이터 변경이 얼마나 일어날까요? 오영일이라는 회원의 등급이 VIP에서 GOLD로 강등되었다고 가정해봅시다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
111 | T1 | 오영일 | 2025-01-17 | GOLD |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
111 | T3 | 오영일 | 2025-01-17 | GOLD |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
111 | T5 | 오영일 | 2025-01-20 | GOLD |
오영일이 거래한 횟수만큼 데이터를 변경해줘야 합니다. 고객 데이터가 중복으로 저장되면 데이터를 수정할 때, 불필요한 연산이 일어납니다. 만약, 세 개의 데이터 중 한 개를 변경하지 않는다면? 그 때는 데이터의 모순이 발생할 수 있습니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
111 | T1 | 오영일 | 2025-01-17 | GOLD |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
111 | T3 | 오영일 | 2025-01-17 | GOLD |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
111 | T5 | 오영일 | 2025-01-20 | VIP |
이처럼 오영일 고객이 두 개의 등급을 갖게 되는 모순이 발생할 수 있습니다. 중복된 데이터를 수정할 때, 일부만 수정되어 데이터 불일치가 발생하는 모순을 갱신 이상이라고 합니다. 삽입 이상과 마찬가지로 릴레이션이 제대로 분리되지 않았을 때, 발생하는 문제입니다.
3) 삭제 이상
고객-거래 릴레이션에서 오영일 고객이 회원탈퇴를 한다고 가정해봅시다. 그러면, 오영일에 대한 거래 정보까지 함께 삭제해야 합니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
만약, 탈퇴된 회원에 대한 거래 정보까지 관리를 해야한다면, 해당 릴레이션 구조로는 불가능할 것입니다. 고객과 거래 정보가 함께 저장되기 때문에 고객이 삭제된다면 거래도 함께 삭제되어 버리기 때문입니다. 이처럼 데이터를 삭제했을 때, 삭제되면 안되는 데이터까지 같이 삭제되는 것을 삭제 이상이라고 합니다.
4) 정규화의 필요성
예시로 든 고객-릴레이션에는 최대 6개의 데이터만 다뤘지만, 실제로 10만개 혹은 100만개 이상의 데이터를 관리한다면, 이상현상이 비즈니스에 안겨주는 파급 효과는 어마무시할 것입니다. 따라서 각 릴레이션이 연관된 속성만을 갖도록 분리를 시켜야 합니다. 우리는 이것을 정규화라고 하며, 이상현상을 통해 정규화의 필요성을 이해할 수 있습니다.
2. 함수 종속성
정규화를 하기 위해서는 먼저, 릴레이션이 갖고 있는 속성들의 관련성을 파악해야 합니다. 이를 함수 종속성이라고 하며, 각 릴레이션이 연관된 속성만을 갖도록 분리시킨다면, 자연스레 속성들의 관련성은 줄어들며, 단순해질 것입니다.
1) 완전 함수 종속성
함수는 입력 X에 대해 출력 Y를 보장하는 관계라고 할 수 있습니다. 데이터베이스에서의 함수 종속성도 이러한 X와 Y로 나타낼 수 있습니다. 서로 다른 두 개의 속성 X와 Y가 있을 때, 하나의 X가 하나의 Y를 결정할 수 있습니다. 이 때, X를 결정자, Y를 종속자라고 합니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
만약, X를 고객 ID, Y를 고객 이름이라고 가정하겠습니다. 이 때, 고객 ID가 다르면 고객 이름도 달라지게 됩니다. 이는 고객 이름이 고객 ID에 의해 함수적으로 종속된다고 표현할 수 있습니다. 각 릴레이션마다 표현할 수 있는 함수 종속성의 종류는 다양할 수 있습니다.
- 고객 ID -> (고객 이름, 고객 등급)
- 거래 ID -> (거래 날짜, 고객 ID)
- (고객 ID, 거래 ID) -> (고객 이름)
이 때, 거래 ID라는 결정자로 인해 (거래 날짜, 고객 ID)가 종속되는 관계를 살펴보겠습니다. 여기서는 거래 날짜와 고객 ID가 거래 ID가 없이는 결정될 수 없습니다. 따라서 집합 X를 (거래 ID), 집합 Y를 (거래 날짜, 고객 ID)라고 할 때, 집합 Y는 집합 X의 모든 원소들의 조합으로만 종속될 수 있을 때, 완전 함수 종속성이라고 합니다. 쉽게 말해, 정의된 종속 관계에서 결정자가 하나라도 빠졌을 때, 종속 관계가 성립되지 않는다면, 이는 완전 함수 종속성이라고 할 수 있습니다.
2) 부분 함수 종속성
부분 함수 종속성은 집합 X 중 부분 집합 만으로도 집합 Y를 결정할 수 있는 관계를 말합니다.
- 고객 ID -> 고객 이름
- (고객 ID, 거래 ID) -> 고객 이름
고객 이름이라는 종속자는 고객 ID와 거래 ID 조합의 결정자로 결정될 수 있습니다. 하지만, 거래 ID 없이 고객 ID만으로도 결정될 수 있습니다. 이처럼 결정자의 부분 집합만으로도 함수적 종속이 가능한 경우를 부분 함수 종속성이라고 합니다.
3) 이행적 함수 종속성
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 | 할인율 |
131 | T2 | 성기훈 | 2025-01-17 | SILVER | 5% |
141 | T4 | 조상우 | 2025-01-18 | GOLD | 10% |
이번에는 할인율이라는 속성이 추가되었습니다. 이 때, 다음과 같은 함수 종속성을 확인해봅시다.
- 고객 ID -> 고객 등급 -> 할인율
고객 ID(X)를 통해 고객 등급(Y)이 결정됩니다. 또한, 고객 등급(Y)으로 인해 할인율(Z)이 결정됩니다. 따라서 고객 ID(X)로 할인율(Z)를 결정할 수 있습니다. 이처럼, X, Y, Z 속성에 대해 X가 Y를 결정하고, Y가 Z를 결정하면 X가 Z를 결정할 수 있게 됩니다. 이 때, Z는 X에 이행적으로 함수 종속된다고 말합니다.
릴레이션에 이행적 함수 종속성이 발생한다는건 데이터가 중복으로 저장될 수 있다는 뜻이 됩니다. 예를 들어, 같은 고객 등급을 갖는 회원들은 어짜피 같은 할인율을 갖게 됩니다. 따라서 (고객 등급, 할인율)이 중복으로 저장될 수 있습니다. 릴레이션에 여러 개의 함수 종속성이 존재할 때, 이행적 함수 종속성이 존재할 가능성이 높습니다.
3. 정규화
함수 종속성을 통해 릴레이션이 갖는 속성들의 관계를 파악하고, 릴레이션이 연관된 속성들만 갖도록 분해하는 것을 정규화라고 합니다. 이러한 정규화를 통해 앞서 살펴본 이상현상 문제를 최소화할 수 있습니다.
릴레이션이 특정 정규형의 제약조건을 만족한다면, 해당 릴레이션은 그 정규형에 속한다고 표현합니다.
1) 제1 정규형
제1 정규형 제약조건을 만족하는 릴레이션을 제1 정규형 릴레이션이라고 합니다. 제1 정규형은 릴레이션의 속성들이 원자값(더 이상 나눠지지 않는 단위)으로 구성되는 것을 말합니다.
https://whxogus215.tistory.com/145
1. DB와 RDB의 기본 개념
1. 파일 시스템과 데이터베이스의 차이1) 파일 시스템파일시스템은 컴퓨터를 사용하는 우리들에게 가장 익숙한 데이터 저장방식입니다. 엑셀 시트, 메모장, 이미지 등 다양한 형태의 데이터가 SS
whxogus215.tistory.com
관계형 데이터베이스가 무결성 제약조건을 준수해야 하는데, 이를 통해 도메인 무결성을 보장할 수 있습니다. 바로 릴레이션의 각 속성들은 원자값을 가져야 한다는 것입니다. 따라서 관계형 데이터베이스에서 릴레이션으로 존재하기 위해서는 최소한 제1 정규형을 만족해야 합니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
고객-거래 릴레이션의 경우, 각 속성들이 하나의 값만 갖고 있습니다. 만약, 하나의 거래 ID에 대해 두 명 이상의 고객 이름이 존재한다면, 이는 제1 정규형이 아닙니다. 이 때는 제1 정규형을 만족하기 위해서 같은 거래 ID에 대해 두 개의 튜플로 저장해야 합니다.
고객-거래 릴레이션은 제1 정규형을 만족하지만, 이상현상이 발생할 우려가 있습니다.
- 삽입 이상 : 거래가 없는 신규 고객을 저장해야 할 경우, 데이터를 추가하기 위해, 관련없는 거래 데이터도 추가해야 합니다.
- 갱신 이상 : 만약, 고객이 여러 거래를 갖고 있을 경우, (고객 ID, 고객 이름, 고객 등급)이 중복으로 저장될 수 있습니다. 이 때, 고객의 이름 혹은 등급이 변경된다면 중복된 데이터를 모두 수정해야 합니다. 중복된 데이터 중 하나라도 수정하지 않으면 데이터의 일관성이 깨지게 됩니다.
- 삭제 이상 : 고객이 거래를 했으나, 거래 취소를 할 경우, 고객-릴레이션에서 해당 거래를 삭제해야 합니다. 하지만 거래 데이터를 삭제할 경우, 고객 데이터까지 함께 삭제됩니다.
이처럼 제1 정규형으로 인해 발생하는 이상 현상을 제거하기 위해 제2 정규화를 합니다.
2) 제 2 정규형
제2 정규형은 제1 정규형을 만족하는 릴레이션에 적용할 수 있습니다. 우리는 앞서 함수 종속성에 대해 알아보았고, 정규화를 통해 복잡한 함수 종속성을 간소화할 수 있다고 했습니다.
고객 ID | 거래 ID | 고객 이름 | 거래 날짜 | 고객 등급 |
131 | T2 | 성기훈 | 2025-01-17 | SILVER |
141 | T4 | 조상우 | 2025-01-18 | GOLD |
제1 정규형을 만족하는 고객-거래 릴레이션에서는 다음과 같은 함수 종속성이 존재합니다.
- (고객 ID, 거래 ID) -> 고객 이름
- 고객 ID -> 고객 이름
고객 이름은 고객 ID과 거래 ID에 의해 종속되면서 고객 ID만으로도 종속됩니다. 우리는 고객 이름이라는 속성이 부분 함수 종속되어 있다고 표현합니다. 제1 정규형에 이상 현상이 발생하는 경우는 릴레이션에 이러한 부분 함수 종속성이 존재할 때 입니다. 따라서 제2 정규형 릴레이션은 "기본 키를 제외한 모든 속성"이 "기본 키"에 대해 완전 함수 종속임을 만족합니다.
고객-거래 릴레이션이 제2 정규형을 만족하도록 고객과 거래 릴레이션으로 분리시켜보겠습니다. 이로 인해, 고객 이름은 고객 ID에 의해서만 결정되는 완전 함수 종속성을 갖습니다.
고객 ID | 고객 이름 | 고객 등급 |
131 | 성기훈 | SILVER |
141 | 조상우 | GOLD |
151 | 오영일 | GOLD |
거래 ID | 거래 날짜 |
T2 | 2025-01-17 |
T4 | 2025-01-18 |
- 고객 ID -> 고객 이름
- 고객 ID -> 고객 등급
- 거래 ID -> 거래 날짜
이제 각 릴레이션의 기본키인 고객 ID와 거래 ID가 다른 속성들의 결정자로 존재하는 완전 함수 종속성만이 남아있습니다.
하지만, 여전히 제2 정규형에서도 이상 현상이 발생할 수 있습니다.
- 삽입 이상 : BRONZE라는 고객 등급이 추가될 경우, 존재하지 않는 고객을 추가해야 합니다.
- 갱신 이상 : GOLD라는 등급의 명칭이 골드라고 바뀐다면, GOLD인 모든 튜플의 데이터를 갱신해야 합니다.
- 삭제 이상 : 고객이 삭제될 경우, 고객 등급까지 같이 삭제됩니다. GOLD인 고객이 전부 삭제된다면, GOLD 등급의 데이터는 존재하지 않게 됩니다.
이는 고객 릴레이션에서 이행적 함수 종속이 존재하기 때문입니다.
- 고객 ID -> 고객 이름
- 고객 이름 -> 고객 등급
고객 ID가 고객 이름을 결정하고, 고객 이름은 고객 등급을 결정합니다. 이는 앞서 이행적 함수 종속에 나왔던 X -> Y -> Z 관계입니다. 따라서 고객 ID가 고객 등급을 결정할 수 있는 관계가 됩니다. 이러한 이행적 함수 종속을 제거함으로써 릴레이션을 다시 한 번 분리하는 것을 제3 정규화라고 합니다.
3) 제 3 정규형
제2 정규형 릴레이션인 고객 릴레이션에는 이행적 함수 종속이 존재합니다. 따라서 다음과 같이 릴레이션을 분해함으로써 이행적 함수 종속을 제거할 수 있습니다.
고객 ID | 고객 이름 | 등급 ID (외래 키) |
131 | 성기훈 | 001 |
141 | 조상우 | 002 |
151 | 오영일 | 002 |
등급 ID | 고객 등급 |
001 | SILVER |
002 | GOLD |
다음과 같이 고객과 등급 릴레이션으로 분해하였습니다. 이로 인해 "기본 키를 제외한 모든 속성"이 기본 키에 대해 완전 함수 종속되며, 이행적 함수 종속은 존재하지 않습니다.
- 고객 ID -> 고객 이름
- 고객 ID -> 등급 ID
- 등급 ID -> 고객 등급
릴레이션에 여러 개의 속성이 존재할 경우, 여러 개의 함수 종속성이 존재할 수 있습니다. 이 때, 부분 함수 종속성, 이행적 함수 종속성을 따져보고, 이들을 제거하여 단순화하는 방향으로 정규화를 진행할 수 있습니다.
4) BCNF 정규형
제1,2,3 정규형의 예시를 들면서 각 릴레이션에는 후보키가 한 개만 존재하였습니다. 제3 정규형을 만족하는 새로운 릴레이션을 예로 들어보겠습니다.
학번 | 과목코드 | 교수 번호 | 학과 |
1001 | CS101 | 001 | 컴퓨터 |
1001 | CS102 | 002 | 전자 |
1002 | CS103 | 003 | 네트워크 |
해당 릴레이션은 부분 함수 종속과 이행적 함수 종속이 존재하지 않습니다. 또한 가능한 후보키는 다음과 같습니다.
- (학번, 과목코드)
- (학번, 교수번호)
하지만 이 때, 교수 번호라는 결정자가 학과라는 속성을 결정합니다. 따라서 제3 정규형을 만족하지만 후보키가 아닌 속성이 결정자가 될 경우, BCNF 제약조건을 위반한다고 할 수 있습니다.
- 삽입 이상 : 만약 004라는 번호를 갖는 새로운 교수가 임용되었다고 했을 때, 아직 담당 학생이 없으므로 학번에 NULL이 들어가야 합니다. 하지만, 이는 개체 무결성 제약조건(기본키는 NULL이면 안됨)을 위반하게 됩니다.
- 갱신 이상 : 만약 001번 교수님의 소속 학과가 변경된다면, 001번 교수님의 데이터가 있는 모든 튜플을 갱신해야 합니다.
- 삭제 이상 : 만약 003번 교수님이 은퇴를 하게 되어 데이터를 삭제해야 할 경우, 1002번 학생에 대한 정보도 삭제될 수 있습니다.
이는 교수번호라는 후보키가 아닌 결정자가 다른 속성을 결정하기 때문에 발생하는 문제입니다. 따라서 교수 번호는 학과를 결정하는 교수 릴레이션으로 분리시킬 수 있습니다.
학번 | 과목코드 |
1001 | CS101 |
1001 | CS102 |
1002 | CS103 |
교수 번호 | 학과 |
001 | 컴퓨터 |
002 | 전자 |
003 | 네트워크 |
이처럼 학번과 과목코드를 기본키로 갖는 릴레이션과 교수번호를 기본키로 갖는 릴레이션으로 분리할 수 있습니다. 이제 후보키가 아닌 속성이 결정자가 되지 않습니다. BCNF 정규형은 제3 정규형에서 더 엄격한 제약조건이 추가되었다고 하여 강한 제3 정규형이라고도 합니다.
5) 반정규화
정규화를 하면, 릴레이션에 존재하는 함수 종속성이 줄어들게 되고, 이는 곧 릴레이션이 분리됨을 의미합니다. 분리된 두 릴레이션은 조인을 통해 결합할 수 있습니다. 따라서 릴레이션이 분리되면 분리될 수록, 조회 연산 시 많은 조인을 할 우려가 발생합니다.
반정규화는 성능 향상, 개발 편의성 등을 위해 정규화를 준수하는 릴레이션을 다시 통합하거나 분해함으로써 정규화 원칙을 의도적으로 위반하는 것을 말합니다. 반정규화를 통해 복잡한 데이터를 보다 편리하게 관리할 수 있다는 이점을 얻되, 데이터의 일관성이 깨지는 위험이 발생할 수도 있습니다.
[1] 테이블 통합
학번 | 이름 | 학과코드 |
1 | 김철수 | 101 |
2 | 박영희 | 102 |
3 | 이민수 | 101 |
학과코드 | 학과명 |
101 | 전자 |
102 | 컴퓨터 |
만약, 특정 학생에 대한 학과명을 가져오려면 두 테이블(릴레이션)을 조인해야 합니다. 두 테이블을 각각 조회하는 것보다 조인된 테이블을 조회하는 경우가 많다면, 차라리 두 테이블을 통합하여 관리할 수도 있습니다.
학번 | 이름 | 학과코드 | 학과명 |
1 | 김철수 | 101 | 전자 |
2 | 박영희 | 102 | 컴퓨터 |
3 | 이민수 | 101 | 전자 |
이렇게 되면 학생 + 학과 정보를 하나의 테이블로 확인할 수 있습니다. 다만, 학과명에 대한 변경이 일어나면 갱신 이상이 발생할 우려가 존재합니다. 테이블 간 조인이 자주 이뤄지고, 검색 성능이 매우 중요하다면 반정규화 중 테이블 통합을 사용할 수 있습니다.
[2] 중복 칼럼 추가
주문 테이블에 주문 정보 이외에 상품 정보도 함께 추가하면, 주문 테이블과 상품 테이블을 조인하지 않고도 주문에 대한 상품 정보를 빠르게 확인할 수 있습니다.
주문 ID | 주문자 성함 | 상품 이름 | 상품 가격 |
001 | 김철수 | 오레오 민트초코맛 | 2000 |
002 | 김철수 | 오레오 딸기맛 | 2000 |
003 | 박영희 | 스니커즈 쿠앤크맛 | 1500 |
해당 테이블은 제1 정규형을 만족하지만, 제2 정규형은 만족하지 않습니다. 기본키는 (주문 ID, 주문자 성함)이지만, 상품 이름은 주문ID만으로도 결정되기에 부분 함수 종속성이 존재하기 때문입니다. 하지만, 주문 정보와 상품 정보를 함께 조회해야 하는 경우가 많을 경우, 다음과 같이 상품 테이블에 존재하는 두 속성(상품 이름, 상품 가격)을 중복으로 추가하여 조회 성능을 개선할 수 있습니다. 하지만, 이 또한 마찬가지로 갱신 이상의 우려가 있고, 데이터 중복 저장으로 인해 저장공간이 낭비될 수 있습니다.
참고 자료:
https://terms.naver.com/entry.naver?docId=3431238&cid=58430&categoryId=58430&expCategoryId=58430
정규화
[Preview] 여러분은 관계가 서먹하거나 싫어하는 사람이 있는가? 혹은 싫어하는 동물이 있는가? 싫어하는 사람이나 동물과 같이 살아야 된다면 어떨까? 당연히 유쾌하지 않을 것이다. 같이 살면서
terms.naver.com
[2021 정보처리기사-3과목] 반정규화(Denormalization)
[정보처리기사 3과목 필기 예상 키워드] 목록으로 돌아가기 과목: 3. 데이터베이스 구축 챕터: 1장 논리 DB 설계 키워드: 반정규화(Denormalization) #반정규화 목차 반정규화(Denormalization)의 개념 반정
y-oni.tistory.com
'CS > 데이터베이스' 카테고리의 다른 글
5. 트랜잭션과 회복 (0) | 2025.01.29 |
---|---|
3. 인덱스 (0) | 2025.01.16 |
SELECT FOR UPDATE의 권한 범위 (0) | 2025.01.11 |
2. SQL (0) | 2025.01.07 |
1. DB와 RDB의 기본 개념 (0) | 2024.12.31 |