정규화(Normalization)란?
: 어떤 대상을 일정한 규칙이나 기준에 따르는 '정규적인' 상태로 바꾸거나, 비정상적인 대상을 정상적으로 되돌리는 과정을 뜻한다. 특히, RDB(관계형 데이터베이스)에서는, 이상 현상이 존재하는 릴레이션을 분해하여, 여러 개의 릴레이션으로 생성하는데, 이를 단계별로 구분하여 정규화 과정이 고도화될 수록 이러한 이상 현상을 줄일 수 있다.
그렇다면, DB에서의 '이상 현상(Anomaly)'이란 무엇일까?
불필요한 데이터 중복으로 인해 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 문제 또는 DB의 무결성을 저해하는 부작용을 말한다.
기본적으로 DB에서 말하는 이상 현상은 크게 다음과 같이 3가지이다.
- 삽입 이상(Insertion Anomaly)
- 삭제 이상(Deletion Anomaly)
- 갱신 이상(Update Anomaly)
1. 삽입 이상이란?
: 레코드를 테이블에 삽입할 때, 의도하지 않은 데이터까지 삽입을 해야만, 해당 레코드를 테이블에 추가가 가능한 현상
예시)
Q. 사원 테이블을 다음과 같이 구성했을 때, 새로운 부서에 대한 부서 이름만 추가하고 싶어요. 그런데, 주민등록번호가 기본키여서, Not null 제약조건이 걸려 있어요. 어떻게 해야 할까요?
A. 그 [사원] 테이블을 둘로 쪼개세요! [사원] 테이블과 [부서] 테이블을 따로 관리하면 됩니다.
2. 삭제 이상이란?
: 어떤 레코드를 삭제하면, 의도하지 않은 다른 데이터까지 삭제되어 버리는 현상
예시) [사원] 테이블
E_NAME | B_DATE | ADDRESS | D_NUMBER | D_NAME | D_MANAGER |
정재호 | 2024.01.04 | 인천 | 101 | IT팀 운영파트 | 이상철 |
홍인광 | 2024.01.04 | 김포 | 102 | IT팀 개발파트 | 박종인 |
김가희 | 2023.05.01 | 서울 광진구 | 103 | 인사총무팀 인사파트 | 안주은 |
연동호 | 2003.01.03 | 파주 | 104 | QA팀 | 김유이 |
Q. '김유이'라는 매니저가 퇴사해서, [사원] 테이블에서 '김유이'라는 데이터를 삭제하고 싶은데, 그러면 '연동호' 사원 데이터까지 모두 사라져버려요. 어떻게 해야 될까요?
A. 다음과 같이 [사원] 테이블과 [부서] 테이블로 나누세요!
[사원] 테이블
E_NAME | B_DATE | ADDRESS |
정재호 | 2024.01.04 | 인천 |
홍인광 | 2024.01.04 | 김포 |
김가희 | 2023.05.01 | 서울 광진구 |
연동호 | 2003.01.03 | 파주 |
[부서] 테이블
D_NUMBER | D_NAME | D_MANAGER |
101 | IT팀 운영파트 | 이상철 |
102 | IT팀 개발파트 | 박종인 |
103 | 인사총무팀 인사파트 | 안주은 |
104 | QA팀 | 김유이 |
3. 갱신 이상이란?
: 중복된 데이터 중 일부만 수정되어 데이터 모순이 일어나거나, 한 데이터 수정이 불필요한 수많은 데이터 수정을 야기하는 현상
예시) [주문] 테이블 ver.1 (총 매출 : 38,000원 / 입금된 금액 : 38,000원)
주문자명 | 주문상품 | 상품 금액 | 배송지 | 배송상태 |
정재호 | 닭가슴살 | 10,000 | 인천 | 배송 중 |
정재호 | 닭가슴살 | 10,000 | 진천 | 배송 준비중 |
홍인광 | 고구마 | 3,000 | 김포 | 배송 중 |
홍인광 | 소고기 | 15,000 | 김포 | 배송 완료 |
[주문] 테이블 ver.2 (총 매출 : 78,000원 / 입금된 금액 : 58,000원)
주문자명 | 주문상품 | 상품 금액 | 배송지 | 배송상태 |
정재호 | 닭가슴살 | 20,000 | 인천 | 배송 완료 |
정재호 | 닭가슴살 | 20,000 | 진천 | 배송 완료 |
홍인광 | 고구마 | 3,000 | 김포 | 배송 완료 |
홍인광 | 소고기 | 15,000 | 김포 | 배송 완료 |
정재호 | 닭가슴살 | 20,000 | 인천 | 배송 준비중 |
Q. 미친 인플레이션 때문에 닭가슴살 가격을 10,000원 -> 20,000원으로 인상해야 해요. 그런데 이렇게 올리고 나면, [주문] 테이블을 기준으로 매출을 계산하는 저희 회사는, 입금된 금액이랑 총 매출이랑 맞지 않게 돼요. 어떻게 해야 할까요?
A. [상품] 테이블 [주문] 테이블을 나눠서 관리하세요! 그럼 상품 가격의 변동이 있을 때, [상품] 테이블에서의 '상품 가격' 컬럼만 수정하면, 상품 가격 변동 이전에 [주문] 테이블에 들어간 데이터는 변경되지 않을 수 있습니다.
[상품] 테이블
상품명 | 상품 가격 |
닭가슴살 | 20,000 |
고구마 | 3,000 |
소고기 | 15,000 |
[주문] 테이블 (총 매출 : 58,000원 / 입금된 금액 : 58,000원)
(닭가슴살 가격이 10,000 -> 20,000 원으로 인상되어도, 이전에 주문된 닭가슴살의 주문 금액은 바뀌지 않으므로, 입금된 금액이랑 총 매출이 다르게 될 위험이 없음.)
주문자명 | 주문상품 | 주문 금액 | 배송지 | 배송상태 |
정재호 | 닭가슴살 | 10,000 | 인천 | 배송 완료 |
정재호 | 닭가슴살 | 10,000 | 진천 | 배송 완료 |
홍인광 | 고구마 | 3,000 | 김포 | 배송 완료 |
홍인광 | 소고기 | 15,000 | 김포 | 배송 완료 |
정재호 | 닭가슴살 | 20,000 | 인천 | 배송 준비중 |
여기까지 봤다면, 이런 궁금증이 생길 것이다.
"대체 테이블을 쪼개는 기준이 뭐지? 그때그때의 상황마다 다른건가?
그런데, 그렇게 상황마다 테이블 스키마를 변경하려면 DB 작업 시간 잡느라 Downtime도 잡아야 하고, 컬럼을 늘릴 때 데이터 제약조건은 어떻게 잡을 지, 제약조건에 따른 Null값은 어떻게 처리할지, 만약 다른 상황이 생긴다면 설계된 테이블을 계속 쪼개기만 하면 되나...? 하아.. 이거 수정하는 거에 따라서 애플리케이션도 다 변경해야 하는데..."
와 같은 수많은 문제에 직면하게 된다.
이런 문제를 여러 번 경험한 데이터베이스 이론가들은 일종의 정규화에 대한 규칙이 고민하고 확립하게 된다.
이를 다음 포스팅에서 알아보도록 하자!
https://co-no.tistory.com/entry/RDBMS
참고
https://dev-coco.tistory.com/63
'DB' 카테고리의 다른 글
[RDBMS] DB의 정규화 단계(1NF, 2NF, 3NF, BCNF, 4NF, 5NF)의 개념 및 예시 (1) | 2024.01.07 |
---|---|
[DB공통] OLTP vs OLAP 개념, 용도, 차이점 등 (0) | 2022.06.20 |
[DB공통] DB 성능을 위한 모니터링 지표 10가지 (0) | 2022.01.18 |
최근댓글