7_Oracle DDL 테이블 생성 시 제약 조건, 정규화(ANOMALY)

 

 

7_Oracle DDL 테이블 생성 시 제약 조건, 정규화(ANOMALY)

 

 

이 이상현상들은 정규화 라는 과정을 통해 방지할 수 있습니다.

정규화는 쉽게 말하면 테이블을 쪼개는 것입니다.

 

 

 

정규형에는 6가지 정도의 정규형이 있지만, 너무 많이 쪼개면 오히려 더 비효율적이게 될 수 있습니다.

여기서는 제 3 정규형까지만 알아보겠습니다.

 

 

1-1_제 1 정규형 위배

이 테이블을 보시면, 이벤트 번호에 너무 많은 정보들이 들어가 있다는 걸 알 수 있습니다.

가독성도 떨어지고, 직관성도 떨어지죠

이렇게 되면 데이터를 입출력하기도 힘들어집니다.

 

 

 

1-2_제 1 정규형_데이터 테이블의 열 안에 하나의 정보만 표시

이렇게 열을 나누면 열 안에 하나의 정보만 표시가 되는 것을 알 수있습니다.

 

 

 

2-1_제 2 정규형 위배

이 테이블에서는

만약 고객ID가 1번인 고객의 등급을 바꾸고 싶을 때

하나하나 다 바꾸다가는 데이터 오류가 날 수도 있고, 실수를 할 수도 있게 됩니다.

이렇게 기본키와 직접적으로 관계가 없을 시에는 제 2 정규형 위배가 됩니다.

 

 

 

2-2_제 2 정규형_기본키가 아닌 모든 컬럼이 기본키와 관계가 있음

이렇게 테이블을 나누면 고객 테이블에서만 등급을 바꿔주면 해결할 수 있습니다.

이렇게 기본키가 아닌 모든 컬럼이 기본키와 관련이 있게 테이블을 나누는 것을 제 2 정규형이라고 합니다.

그니까 고객1번은 등급이 이거고 할인율은 이거다 고객1번의 이벤트는 이거고 당첨이 되었다

이렇게 기본키인 고객과 연관이 있게 쪼개진 것입니다.

 

 

3-1_제 3 정규형 위배

이 고객 테이블을 보시면

고객id의 등급, 이 등급의 할인율 이렇게 정의가 되죠.

이렇게 등급과 할인율이 직접적으로 관계가 있기 때문에 제 3 정규형에 위반이 됩니다.

만약 여기서 고객 등깁이 변경되었을 때 할인율까지 다 바꿔줘야 하기 때문입니다.

 

 

 

3-2_제 3 정규형_기본키가 아닌 모든 컬럼이 직접적 관계가 없음음

그래서 이거를 또 이렇게 쪼개주면 각 컬럼들이 직접적 관계가 없게 됩니다.

고객의 등급이 이거고, 등급의 할인율이 이것이다.

이렇게 쪼개주면, 고객 등급이 변경되었을 때, 고객 등급만 변경해주면 데이터를 쉽게 변경해 줄 수있게 됩니다.