일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- intelij spring config
- m:n
- BindingResult
- Git
- API
- 편향된 지수
- 프로그래머스
- DTO
- 오블완
- 리눅스
- 알고리즘
- @Autowired
- 무한정 대기
- JDBC
- JPA
- 은행원알고리즘
- allocationSize
- 파이썬
- @SubscribeMapping
- 쉘 스크립트
- 런타임 상수
- 기본키 전략
- 커밋 되돌리기
- compgen
- 백준
- 티스토리챌린지
- 컴파일 타임 상수
- spring
- 쿠키
- application layer
- Today
- Total
둘셋 개발!
[RDBMS] 정규화 필요성, 과정(1정규화, 2정규화, 3정규화, BC정규화, 역정규화) 본문
DB를 설계 할 때 '정규화'과정을 거친다고 말한다.
정규화는 무엇이고, 왜 해야 할까??
✔️ 정규화란?
: 이상현상이 있는 테이블을 분해햐여 이상현상을 없애는 과정
여기서 이상현상이란 불필요한 데이터 중복으로 인해 테이블에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 부작용이다.
따라서 정규화를 하는 이유는 중복을 허용하지 않기 위해!! 라고 정리할 수 있겠다.
✔️ 정규화 과정
정규화는 과정에는 여러 단계가 존재하지만 이번 포스팅에서는 대표적으로 1정규화, 2정규화, 3정규화, BC정규화, 역정규화를 다룰 것이다.
- 1정규화
: 데이터가 원자성을 가질 수 있게 함. (원자성: 더이상 쪼개질 수 없는 성질)
원자성을 해칠 수 있는 것들 중에 대표적으로 다가속성, 복합속성이 있다.
1. 다가속성
다가속성이란 한 데이터안에 여러 값들이 나열된 형태를 말한다.
예를 들면 다음과 같다.
회원 전화번호라는 컬럼의 값으로 여러 전화번호가 컴마로 나열되어 있다.
데이터는 더이상 쪼갤 수 없는 원자성을 가져야 하는데 이를 위반하였다.
회원 전화번호의 컬럼을 쪼개면 다음과 같다.
2. 복합속성
복합속성이란 한 데이터 안에 복합적인 요소가 들어가 있는 것을 말한다.
위의 회원 테이블을 예로 들면 회원명이 복합속성을 가졌다고 할 수 있다.
회원명은 성 + 이름 으로 나눌 수 있기 때문이다.
복합속성을 쪼개면 다음과 같다.
이렇게 다가속성과 복합속성을 해결하여 1정규화를 해보았다!!
- 2정규화
: 기본키에 속하지 않은 모든 속성이 기본키에 완전 종속적
이게 무슨말이지는 예시를 통해 알아보도록 하자.
다음은 2정규화를 지켜지지 않은 예시들이다.
여기서 기본키에 속하지 않는 컬럼은 상품명, 단가, 주문 수량이다.
이 컬럼들이 기본키인 (주문번호, 상품번호)에 종속적인지 아닌지를 판단하면 되는 것이다.
먼저 상품명은 상품번호에만 종속적이고 주문번호에는 종속적이지 않다. 상품번호가 정해지면 상품명을 저절로 결정이 된다.
하지만 주문번호에는 상품명에 아무런 영향을 미치지 않는다.
그다음 단가도 상품명과 마찬가지로 상품번호에는 종속이지만 주문번호에는 종속적이지 않다. 상품번호가 정해지면 그 상품의 단가는 정해져 있기 때문이다.
주문수량만이 기본키에 완전 종속적이다. 어떤 상품을 몇 개 주문한 것인지는 주문 별로 다 다르다. 따라서 주문수량은 (주문번호, 상품번호)에 종속적이라고 말할 수 있다.
그래서 2정규화를 시켜보면
상품명과 단가는 상품번호에 종속적이기 때문에 상품 테이블을 따로 만들고 주문 상품 테이블과 1:m 관계를 맺어주는 것이다.
- 3정규화
: 식별자가 아닌 일반 속성 간에는 종속성이 존재하지 않아야 함
조금 풀어서 설명하자면, 식별자에 종속적이여야 하는데 어떤 한 속성이 식별자가 아닌 일반속성에 종속적이면 안된다는 말이다.
예시로 보자!
여기서 문제는 '상품명'과 '단가'가 식별자가 아닌 '상품번호'에 종속적이라는 것이다.
따라서 이 테이블을 3정규화 해주면 다음과 같을 수 있다.
- BC 정규화
: 일반 컴럼이 후보키를 결정하지 않아야 함
BC 정규화는 3정규화를 보안한 정규화라고 볼 수 잇다.
3정규화를 거쳐도 해결 할 수 없는 이상현상을 해결할 수 있는 것이 BC 정규화 이다.
예시를 통해 자세히 알아보도록 하자.
다음과 같이 수강 테이블이 있다.
가정으로 한 명의 교수는 한 과목만 강의할 수 있다고 치자.
이 말은 즉슨 교수 데이터가 있으면 과목 데이터는 자동으로 결정된다는 이야기 이다. 반대로도 마찬가지.
그러면 이 테이블의 문제는 후보키가 아닌 과목 ID가 후보키인 교수ID를 결정하는 것이다.
따라서 중복이 발생할 수 있는 위험이 있기 때문에 테이블을 분리해주는 작업이 필요하다.
- 역정규화
: 효율을 위해서 일부로 중복을 만드는 것
대부분 join시에 발생되는 엄청난 계산양을 해결하기 위해 역정규화를 해준다.
예를 들어 다음과 같은 테이블이 있다고 해보자.
여기서 문제점은 상품명은 상품번호만 종속적이므로 2정규화를 위반하였다.
하지만 실제로 서비스를 진행하다보니 주문상품 테이블을 조회할 때 매번 '상품명'이라는 속성이 필요하여 상품 테이블을 조인하여서 상품명을 조회를 해야 한다면...?? 차라리 주문 상품 테이블에 상품명이라는 속성을 넣는 것이 효율성으로 따지면 더 좋다..!!
결론: 정규화 과정을 거쳐 중복을 없애자!!
- 참고 사이트
https://3months.tistory.com/193
https://zz132456zz.tistory.com/36
https://minimax95.tistory.com/entry/정규화Normalization-개념과-기본-과정
'데이터베이스' 카테고리의 다른 글
[RDBMS] 1:1 관계 (정의, 올바른 테이블 설계, 실제 활용 예시) (0) | 2023.03.20 |
---|---|
[RDBMS] m:n관계를 찾는 방법 (0) | 2023.03.19 |
[RDBMS] M:N 테이블 설계 (특징, 예시, 테이블 설계 시 고려할 점) (0) | 2023.03.19 |
[RDBMS] 1:M 테이블 설계 시 고려할 점 (정의, 고려할 점, 재귀적 관계) (0) | 2023.03.19 |
[RDBMS] Primary Key의 조건, Primary Key를 설정할 때 고민이 필요한 부분 (0) | 2023.01.16 |