[Database] Normalization(정규화)
이번 포스팅에서는 데이터베이스의 Normalization(정규화)에 대한 내용을 담고 있습니다.
"조직화하고 정리하는 것은 커다란 테트리스 게임과 같다"
--알레한드라 코스텔로
[Intro]
만일 서랍정리를 할때 전자기기들은 두번째 서랍에 넣기로 하고
흰색 물건들은 첫번째 서랍에 넣기로 했다면
흰색 전자기기는 어느 서랍에 넣는 것이 맞을까요?
이런 현상을 데이터베이스에서는 Anomaly(이상 현상)이라고 합니다.
Anomaly가 발생하지 않게끔 기준을 명확하게 해주어 데이터의 무결성을 보장해주는 것을
데이터베이스에서는 정규화라고 합니다.
[Anomaly__이상 현상 ]
이상 현상
불필요한 데이터 중복으로 인해 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을
수행할 때 발생할 수 있는 부작용
종류
- 삽입 이상 : 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
- 갱신 이상 : 중복 튜플 중 일부만 변경하여 데이터가 불일치하게 되는 모순의 문제
- 삭제 이상 : 튜플을 삭제하면 꼭 필요한 데이터까지 함께 삭제되는 데이터 손실의 문제
데이터베이스의 설계를 잘못했을 때, 불필요하게 데이터가 중복으로 저장될 수 있습니다.
이러한 경우 리소스가 낭비되고 운영상 의도치 않은 부작용이 발생할 수 있습니다.
-
Insertion Anomaly
: 데이터를 저장할 때 원하지 않는 정보가 함께 삽입되어야 하는 경우
위 그림에 보듯이 테이블에 값을 넣고자 하는데 여태까지 교육과정은 Course Code가
존재 하지 않는 경우는 없었습니다.
이러한 신규 데이터를 삽입하기 위해서는 수강코드 없음과 같은 코드명을
새로 만들어 주어야 합니다. 이러한 상황을 삽입 이상이라고 합니다.
-
Update Anomaly
: 중복된 튜플 중 일부의 속성만 갱신 시킴으로써 정보의 모순성이 발생하는 경우
519번 직원이 이사를 한 후에 목공 스킬을 익혀 새로운 해당 정보를 입력하게된다면 이사 전의
주소는 갱신되지않아 데이터의 오류가 생기게 되고 이를 갱신 이상이라고 합니다.
-
Deletion Anomaly
: 튜플을 삭제함으로써 유지되어야 하는 정보까지도 연쇄적으로 삭제되는 경우
389번 교직원의 영어강좌가 폐강되어 해당 강좌를 삭제할 경우 해당 교직원의 이름과 고용일,
ID 까지 함께 튜플단위로 연쇄적으로 삭제되어 버리며, 이는 정보의 손실이 생길 수 있습니다.
이를 삭제 이상이라고 합니다.
왜 이런 문제가 발생할까요?
위와 같은 이상현상들이 발생하는 이유는 정규화가 되어 있지 않은 테이블 설계 때문입니다. 코딩할 때에도 관심사를 분리하면 코드의 재사용성과 유지보수의 편의성이 높아지는 것처럼 데이터베이스 설계에서도 비슷한 원칙이 적용됩니다. 데이터베이스 설계의 경우 관심사를 분리하지 않아 생기는 문제는 코드에서의 문제보다 훨씬 치명적입니다.
이론적으로는 정규화를 수행하려면 속성들간의 관련성을 파악해야 하는데,
이 속성들간의 관련성을
함수적 종속성(Functional Dependency)
이라고 합니다.
일반적으로 하나의 릴레이션에는
하나의 함수적 종속성만이 존재하도록 정규화를 하게 됩니다.
[Purpose]
따라서 이러한 이상현상을 해소하고, 불필요한 데이터의 중복을 최소화하는 것이
정규화의 목적이라고 할 수 있습니다. 또한 데이터베이스 구조를 확장시킬시 재디자인을
최소화하고, 다양한 관점에서의 쿼리를 지원할 수 있게 해줍니다.
[Target]
대규모 온라인 티켓 시스템과 같은 OLTP(OnLine Transaction Processing) 데이터 베이스는
CRUD(Create, Read, Update, Delete)가 많이 일어나 정규화가 적절합니다.
이와 반대로, 분석 리포트와 같은 OLAP(OnLine Analytical Processing) 데이터베이스는
분석과 리포팅을 위해 사용되기 때문에 연산의 속도를 위해 반정규화를 사용하는게 좋습니다.
반정규화 : 정규화된 시스템을 성능 향상 및 개발과 운영의 단순화를 위해 역으로 정규화를 수행하는 것.
일반적으로 Join을 많이 사용해야 하거나, 대량의 범위를 자주 처리하는 경우와
같이 Select 작업의 중요도가 높다고 판단될때 반정규화를 수행합니다.
[Step of Normalization]
정규화의 단계는 크게 7단계로 나뉘며 다음과 같습니다.
현실에 존재하는 대부분의 릴레이션에서는 BCNF 단계까지 정규화를 진행하면
실제적인 이상현상이 없어지기 때문에 일반적으로 BCNF까지 정규화를 진행합니다.
[Type of Key]
정규화에 앞서 후술되는 내용에 나오는 키의 종류에 대해 먼저 간략히 알아보겠습니다.
- 유일성 : 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야한다.
- 최소성 : 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성만으로 구성되어있어야한다.(키 값에 유일하게 식별하는데 꼭 필요한 키가 아니면 제거)
1. 슈퍼키(Super Key) : 유일성_O / 최소성 _X
[주민등록번호,이름] → 🟢
이름 → 🔴
주민등록번호 → 🟢
2. 후보키(Candidate Key) : 유일성_O / 최소성 _O
쉽게말해 언제든지 기본키가 될수 있는 키입니다.
아이디 → 🟢
I-pin → 🟢
계좌번호 → 🟠
⇒ 테이블이 어떤테이블이냐에따라 후보키가 될수 있고 안될수 있습니다.
(어떤 테이블인지에 따라 유일성이 있기도하고 없기도함)
ex) 고객테이블에선 유일성 만족/ 결제정보테이블에선 같은계좌로 여러건의 거래가 발생
3. 기본키(Primary Key) : 후보키 목록들중에서 선택받은 키
1. Null(결측값)이 없어야함
2. 자주 변경되는 속성이 포함되어있으면 부적절
3. 가급적 단순한 후보키를 선택
4. 외래키 : 다른 릴레이션의 기본키를 참조
1. 제 1 정규화(1NF)
릴레이션에 속한 모든 속성의 값이 원자성(Atomic)
을 확보하면 1NF에 속합니다.
왼쪽의 릴레이션은 1NF를 만족하지 못합니다. 취미가 원자성을 지니지 않고 여러 값을 가지기
때문입니다. 따라서 우측과 같이 원자값을 갖도록 변경해주는 것을 제 1 정규화 라고 합니다.
2. 제 2 정규화(2NF)
-
릴레이션이 제 1 정규형을 만족하고, 기본키가 아닌 속성이 기본키에 완전 함수 종속일때를 의미합니다.
-
즉, 키가 아닌 열들이 각각 키에 의해 결정되는 릴레이션 형태를 말합니다.
부분함수 종속성
속성집합 Y 가 속성집합 X의 전체가 아닌 일부분에도 함수적으로 종속됨을 의미합니다.
아래 그림과 같이 학생번호와 강좌이름이 기본키(Primary Key,이하 PK)라면 강의실은
PK에도 종속되지만 PK의 부분집합인 강좌이름에도 종속(결정되어짐)됩니다.
이러한 상황에 대하여 부분함수 종속성이 있다고 할 수 있습니다.
*결정자, 종속자
아래 그림에서와 같이 어떤 속성을 결정짓는 속성(키값, 화살표의 시작점) 을 결정자,
결정자에 의해 의미가 결정되어지는 속성을 종속자 라고 합니다.
따라서, 아래 그림과 같이 바꿔주어 기본키(Primary Key)가 아닌 모든 속성들이 기본키에 완전 함수 종속이면 2NF에 속합니다.
3. 제 3 정규화(3NF)
-
해당 릴레이션이 2NF를 만족하고 이행적종속(<->직접종속)이 없는 상태를 의미합니다.
-
이행적 종속 : A -> B , B -> C 가 성립할때 , A -> C가 성립되는 함수 종속성을 의미합니다.
위의 상황에서 501학생이 데이터베이스 수업을 스포츠경영학 수업으로 변경한다면,
15000의 수강료인 스포츠경영학 을 20000에 듣게 됩니다. 물론 강좌이름에 따라 수강료를
변경을 해줄 수 있지만 이는 두번의 변경작업을 거쳐야 합니다. 이러한 번거로움을
해결해주는 것이 제 3 정규화입니다.
기존의 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌이름은 수강료를 결정하고 있습니다. 따라서 이 두관계를 아래와 같이 분리해주어야 합니다.
4. BCNF(Boyce–Codd Normal Form)
- 해당 릴레이션이 함수 종속성 X -> Y가 성립할 때 모든 결정자 X 가 후보키인 정규형입니다.
기본키는 (학생번호, 특강이름)이고 교수는 (학생번호, 특강이름)에 완전하게 함수적으로 종속하고 있습니다. 또한, 교수도 특강 이름을 결정하며 결정자의 역할을 하고 있습니다.
다음으로, 모든 결정자가 후보키인지를 확인해야 합니다. (학생번호, 특강이름)은 기본키이므로 당연히 결정자이며 후보키입니다. 하지만 교수는 결정자이면서 후보키가 아니므로 위 그림과 같이 릴레이션을 분리해야 합니다.
대부분의 릴레이션에서는 BCNF까지 정규화하면 실제적인 이상현상이 없어지기 대문에 BCNF까지 정규화를 진행합니다.
[pros and cons]
정규화의 장단점은 다음과 같습니다.
🟢 이상현상들이 발생하는 문제점을 해결할 수 있다.
🟢 정규화된 테이블들과 테이블들 간의 관계들을 사용자에게 제공할 수 있다.
🔴 릴레이션 간의 연산(JOIN)이 많아진다.
🔴 이로 인해, 질의에 대한 응답시간이 느려질 수 있는 경우가 발생할 수도 있다.
[반정규화(De-normalization,비정규화)]
반정규화는 정규화된 데이터베이스를 성능 향상 및 개발,운영의 단순화를 위해 중복 통합,
분리등을 수행하는 데이터 모델링 기법입니다.
디스크 I/O 양이 많아지거나, 테이블간의 경로가 너무 멀어 조인이 많이 발생하여 성능저하가
예상될 경우 반정규화를 수행할 수 있습니다. 일반적으로 Select에 대한 처리 성능이
중요하다고 판단될때 부분적인 반정규화를 고려하게 됩니다.
-
반정규화의 대상
-
자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고,
항상 일정한 범위만을 조회하는 경우 -
테이블에 대량 데이터가 있고 대량의 범위를 자주 처리하는 경우, 성능 상 이슈가 있을 경우
-
테이블에 지나치게 조인을 많이 사용하게 되어 데이터를 조회하는 것이 기술적으로 어려울 경우
-
-
반정규화의 단점
- 반정규화를 과도하게 적용하면 데이터의 무결성이 깨질 수 있고, 입력/수정/삭제의 질의문에 대한 응답시간이 늦어질 수 있다.
[Summary of Nomalization]
Author And Source
이 문제에 관하여([Database] Normalization(정규화)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@jude0124/정규화저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)