내가 읽으려고 하는 데이터베이스 정규화 정리

나는 데이터베이스 수업을 2학년때 일본에서 들었다.

그때의 지식이 나의 머리 뒷편에 남아서 내가 DB 모델링을 할 때 항상 도와주는 느낌적 느낌은 들지만, 시험을 보라고 하면 딱 나오질 않는 느낌의 지식이 되었다.

이러한 방법은 무의식중에 날 도와주지만, 주기적으로 정리하면서 더욱 도움이 되게 할 수 있다. 그러니까 정리한다.

• (https://ko.wikipedia.org/wiki/데이터베이스_정규화) 여기 참고했음
• https://www.studytonight.com/dbms/database-normalization.php 여기도

정규화는 왜 하는가?

• 데이터 중복을 피하려고
• 테이블 간 좋은 관계(여기서는 잘 조직된 관계)를 형성하려고
  • 이러한 좋은 관계를 이루어내기 위해서, 각 단계별 진행하는 과정이 있다.
• 데이터베이스를 잘 쓰려고
  • 다른곳에 있는 같이 바뀌어야되는 데이터를 구조적으로 같이 바뀔 수 있게.
  • 이러한게 수정말고 삽입, 삭제에서도 이루어진다. 같이 되야되는걸 같이 되게.정말로?
• 결국 이렇게 해서, 성능이 개선되고 우리가 일을 잘 할 수 있어야 정규화를 하는 보람이 있을 것이다.
• 이러한 의문이 정규화는 꼭 좋은가?에 대한 답이 될 수 있다.

그럼 정규화는 어떤 행위인가?

• 데이터 중복을 피하게 하기 위해 테이블을 나누던가 한다.
• Primary key, 외래키를 잘 써서 관계를 잘 조성해서 테이블간 이쁘장한 관계를 구축한다. (Hierachy를 구성해서, 원하는 데이터를 맞는 방향으로 찾아가게)
• 등등...

정규화의 단계를 외워보자

이러한 단계는 DB 모델을 점검할 때 좋다. 작은 구조는 눈으로 봤을 때 바로 문제점을 알아챌 수 있지만, 구조가 커지면 다음과 같이 정해진 순서를 밟으며 문제를 확인하는 것이다.
사실 정확히는, 이 조건을 만족하면 n 단계의 정규화를 만족한다이다.

1단계

• Attribute에 여러 값이 아니라 하나의 값만 들어가있다.
• 한 칼럼의 값들은 하나의 도메인에 속해야된다. (칼럼 하나는 하나의 용도로만 쓰자는 것이다.)
• 컬럼들 이름은 unique하게 하지 말자
• 데이터 저장 순서는 영향이 없어야한다.

2단계

• Partial Dependency를 없앤다. (부분 함수 종속성)
• A, B => C 인데, 사실 A => C로 충분할 때, A => C는 부분 함수 종속성을 가진다 한다.
• 제거하려면, A => C를 나누면 될듯.
• https://www.studytonight.com/dbms/second-normal-form.php 참고해봤음.

3단계

• A(key) -> B -> C가 되서 A->C인 관계가 있으면, B -> C를 분리해야한다.
• 2단계랑 반대되는 개념이다. 2단계는 composite key 중 하나의 key로 충분한걸 분리
• (https://www.studytonight.com/dbms/third-normal-form.php) 여길 참고

BCNF(3단계 강화)

• BCNF와 3단계의 차이점은 슈퍼키가 아닌 B에 대해 B->C인 경우가 없어야 한다.이다.
• 3단계 강화인 이유는, 3단계는 Primary와 연결된 B->C만 체크하는데, 이건 그냥 있는 B->C도 체크한다
• 사실 예시가 잘 떠오르지 않는다. 나만 그런건 아닌듯? (https://yaboong.github.io/database/2018/03/10/database-normalization-2/)
• 이유는 보통 테이블을 잘 설계하면 자연스럽게 분리되기 때문이다. 왜 non-primary key가 다른 하나를 결정하지....?
• 그래도 아에 안 생기는 상황은 아니다. stackoverflow에서 피자 예제를 찾았다. https://stackoverflow.com/questions/8437957/difference-between-3nf-and-bcnf-in-simple-terms-must-be-able-to-explain-to-an-8
  • 요약하자면, 피자타입(A), 피자토핑(B), 토핑타입(C) 이 있다 하자. 어떠한 피자 타입을 선택하고 그 안에서 피자 토핑은 바꿀 수 있다 하자. 하지만 토핑타입은 피자토핑에 따라 정해져있다 하자.
  • 이렇다면 A->B는 성립 X, B->C는 성립. 일단 3단계는 성립한다.(피자타입만으로 토핑타입을 특정할 수 없다. 같은 피자 타입에서 토핑은 변경될 수 있기에)
  • 하지만 superkey가 아닌 B가 C를 결정하고 있다. BCNF를 불만족한다.
  • B->C를 별도 테이블로 구분하고 A->B만 가지고 있어야한다.
• 예시를 들으니 또 납득이 가긴 한다.
• https://www.geeksforgeeks.org/difference-between-3nf-and-bcnf-in-dbms/ 도 참고했다.

이 이상은 크게 실용성이 없음.

• 6단계까지 있다고 알고있음

  정규화는 꼭 좋은가?

• 그렇지는 않다.
• JOIN 비용이 증가한다.
• 데이터 국지화 비용 증가
  • 블럭단위의 극한을 달리는 절약이면, 테이블 분리로 비용이 늘어날 수 있음
• https://coolspeed.wordpress.com/2017/04/15/why_not_db_normalization/ 참고

정규화와 NoSQL

• NoSQL은 정규화가 필요없다.
• 애초에 그렇게 하라고 만든게 아니다
  • 스키마의 구조가 계속 바뀐다.
• 할수는 있다.
  • 칼럼 안바꾸면 되지...
  • 정규화는 결국 DB 잘쓰자고 만든것이다. 해보고 만족스러우면 할 만 하다.
• 샤딩, 분산 처리등으로 성능을 이끌어내고있다.