[음악] 네 반갑습니다. 오늘 영상에서는 지난 시간에 배웠던 펑션을 디펜던시를 활용해서

데이터베이스를 정규화하는 방법을 배워보도록 하겠습니다. 자, 그러면 오늘도 고고싱! 자, 먼저 1NF 정규화가

무엇인지 살펴보면 1NF 정규화는 데이터 중복과 또 이상 현상, 업데이트, 삭제, 삽입 문제를 최소화하기 위해 데이터를 노멀 폼에

따라 릴레이션으로 데이터베이스를 구성하는 과정입니다. 그러면 여기서 이 노멀 폼이라는 것은 무엇이냐? 정규화

되기 위해 준수해야 하는 몇 가지 룰들이 있는데요. 이 각각의 룰을 노멀 폼이라고 부릅니다. 그래서 이 노멀 폼을

사용해서 정규화되는 과정을 그림으로 살펴보면 이런 식으로 진행이 되는데요. 맨 처음에 초기 테이블이 있고요. 이

초기 테이블부터 순차적으로 차례차례 첫 번째 놈을 폼부터 이렇게 적용을 하는 거예요 그래서 만약에

노멀 폼을 만족하지 못하면 만족하도록 테이블 구조를 조정한 뒤에 다음 단계로 넘어갈 수 있는 겁니다 이처럼

앞 단계를 만족해야만 다음 단계로 진행할 수 있기 때문에 가령 예를 들어서 어떤 테이블이 3NF를 만족하고

있다고 한다면 그렇다면 이 테이블은 이미 1NF와 2NF도 만족을 하고 있는 거예요 거기에 이제 3NF까지 만족을 하고

있는 거죠 그래서 이렇게 순차적으로 1NF부터 차례차례 적용을 해 나간다 그러면서 중복 데이터를 줄이고

오너머리스도 줄이는 형태로 구조를 바꿔 나간다 이게 데이터베이스의 정규화 과정이다 그렇게 이해를

해주시면 좋을 것 같아요 자 그런데 특히 지금요 부분을 좀 살펴보겠습니다 1nf부터 bcnf까지 이렇게 4개의

노멀 폼은 함수적 종속성과 키만으로 정의되는 노멀 폼입니다 그리고 보통 일반적으로 3nf까지 도달을 하게 되면 이제 이

테이블은 정규화됐다라고 말하기도 해요 그러니까 3nf를 만족하는지가 정규화의 최소 기준이 되는 거죠

그리고 보통 실무에서는 3nf 혹은 bcnf까지만 진행을 합니다 많이 해도 4nf 정도까지만 진행을 해요

여러 가지 구글링을 해보니까 그런 말들이 많더라고요 그 이후에 5nf나 6nf 같은 경우에는 이에 해당하는 어떤 케이스가 발생할

가능성도 매우 적고 상당히 또 복잡하기도 하고 학술적인 측면에서 분석하는 경향성이 더 강하기 때문에

많이 해도 이 4NF까지만 진행을 한다 그렇게 설명을 드리고 싶고요 그러면 오늘 우리는 이 중에서도 이

4가지 BCNF까지만 설명을 드리도록 하겠습니다 왜냐하면 BCNF까지가 펑션널 디펜던시와 키만으로 이 노멀

폼이 정의가 되기 때문에 여기까지 딱 설명하는 것이 깔끔하기도 하고 실제로 실무에서도 3NF혹은

BCNF까지를 많이 적용을 하기 때문에 그 이후에 해당하는 부분들은 따로 설명하지는 않도록 하겠습니다 자 그러면 이제 본격적으로 정규화가

어떻게 진행이 되는지 살펴보도록 하겠습니다 지금 보시면 이렇게 하나의 테이블을 정의를 했어요 이 테이블

가지고 첫 번째 노멀 폼부터 BCNF까지 쭉 설명을 할 거거든요 그렇기 때문에 이 테이블이 어떻게

구성되어 있는지부터 설명을 드리도록 하겠습니다. 먼저 이 테이블은 임직원의 월급 계좌 정보를 관리하는 테이블이에요.

그리고 이 월급 계좌는 국민은행이나 우리은행 중 하나에요. 그렇기 때문에 이 뱅크네임은 국민은행 아니면 우리은행이

두 가지 값만 가지게 될 겁니다. 그 다음에 한 임직원이 하나 이상의 월급 계좌를 등록할 수 있고요. 그리고 그 월급

계좌들 사이에서 어떻게 월급을 분배해서 받을지 그 월급 비율을 조정할 수 있습니다. 그래서 이 레이시오가 각 계좌의 월급 비율이

어떻게 되는지를 저장하는 애트리뷰트라고 그렇게 이해를 해주시면 좋을 것 같아요. 그리고 각 계좌마다 등급이 있습니다. 그래서

국민은행 같은 경우에는 스타로 시작해서 프레스티지, 로얄까지 이렇게 총 3개의 등급이 있고 우리은행 같은 경우에는

브론즈, 실버, 골드라는 이렇게 총 3개의 등급이 존재를 합니다. 그래서 각 개조의 등급은 이 클래스라는

애트리뷰트에서 저장을 하고 있습니다. 그리고 또 한 개조하는 하나 이상의 현금 카드와 연동을 할 수 있어요. 그래서 이 테이블은 은행의 이름,

계좌번호, 얘는 이제 각 개조화를 식별하기 위해서 부여한 아이디인 거죠. 그 다음에 그 계좌에 등급, 계좌가 월급을 어떤

비율로 받을지를 저장하는 레이시오, 그 다음에 임직원의 ID, 임직원의 네임, 그 계좌와 연동된 카드 아이디, 이러한

정보들을 저장하는 테이블이다. 그렇게 보시면 될 것 같아요. 자, 그러면 이제는 이 테이블에 키에 대해서 살펴보도록 하겠습니다.

먼저 이 키에 대한 개념을 복습부터 해볼게요. 슈퍼키라는 용어가 있습니다. 이 슈퍼키는 테이블에서 튜플들을 유니크하게 식별할

수 있는 애트리뷰트들의 집합을 의미합니다. 그 다음에 캔디데이트 키를 추려내서 그냥 키라고도 하는데요

얘는 슈퍼키인데 어떤 슈퍼키냐면 이 슈퍼키에서 어느 한 애트리뷰트라도 제거하면 더 이상

유니크하게 튜플을 식별할 수 없는 슈퍼키. 이런 키를 캔디데이트 키 혹은 줄여서 키라고 부릅니다. 자

그러면 지금 이 테이블에서 키를 한번 찾아볼까요? 먼저 account id가 있을 겁니다. 얘는 각 계좌를 유니크하게 식별하기 위해서

부여한 애트리뷰트이기 때문에 그러니까 당연히 이 어카운트 아이디는 이 튜플들을 유니크하게 식별할 수 있을

거고요. 그 다음에 얘는 애트리뷰트가 단 하나이기 때문에 슈퍼 키이면서도 동시에 캔디데이트 키라고

볼 수 있는 거죠 또 다른 키를 하나 찾아보면 이번에는 이 두 개의 애트리뷰트로 이루어진 집합이 또 다른

키가 될 수 있습니다 테이블에서는 지금 여기에 해당하는 부분인데요 보시면은 이 계좌번호는 서로 다른 은행에서도 우연의 일치로 동일할

수 있잖아요 하지만 각 은행 안에서 계좌번호는 유니크하기 때문에 그러면 그 은행 이름과 계좌번호를 함께

키로 만들게 되면 얘는 이제 이 테이블에 있는 튜플들을 유니크하게 식별할 수 있게 되는 겁니다 이 두 개 중에 하나만

가지고서는 이 튜플들을 유니크하게 식별할 수 없기 때문에 그렇다면 결국 이렇게 이루어진 슈퍼키는 슈퍼키이면서도 동시에 캔디

데이트 키가 될 수 있는 거죠 이해가 되시죠 자 그러면 프라이머리 키는 뭐냐 프라이머리 키는

테이블에서 튜플들을 유니크하게 식별하려고 선택된 캔디데이트 키입니다. 그러니까 지금 보시면 여기서 캔디

데이트 키가 2개가 있는데 이 두 개 중에 하나를 이제 선택을 하는 거예요. 어떤 걸 프라이머리 키로 사용을 할

건지요? 그러면 저는 아무래도 애트리뷰트 수가 더 적은 키가 관리하기도 편하고 여러모로 장점이

많기 때문에 얘를 프라이머리 키로 선택하도록 하겠습니다. 그래서 이제 이 테이블에서 프라이머리 키는 어카운트 아이디가

되는 거예요. 그러면 이 테이블에서는 프라이머리 키 같은 경우에는 언더바로 표시를 해주거든요. 그래서 여기에다가

이제는 이렇게 언더바를 함께 표시를 해 주도록 하겠습니다. 자, 그리고 이번에는 프라임 애트리뷰트가 무엇인지

살펴볼게요 얘는 속하는 애트리뷰트를 의미를 합니다 그러면 지금 이 테이블을 예로 들어 살펴보면 이 테이블에서 키는

얘랑 얘는 거잖아요 그러면 결국 어카운트 아이디, 뱅크네임, 어카운트 넘버가 프라임 애트리뷰트가

되는 거예요 그래서 이 세계의 애트리뷰트가 이 테이블에서는 프라임 애트리뷰트가 되는 거고요 그러면

논 프라임 애트리뷰트는 뭐냐 얘는 프라임 애트리뷰트가 아니면 다 논 프라임 애트리뷰트입니다 그러니까 어떤

키에도 속하지 않는 애트리뷰트들은 모두 논 프라임 애트리뷰트인 거예요 지금 이 예에서는 살펴보면

프라임 애트리뷰트가 이거니까 얘가 아닌 모든 애트리뷰트는 논 프라임 애트리뷰트인 거잖아요 그래서 이렇게 총 5개 위에

테이블 스키마를 보시면 이 부분에 해당하는 거죠. 이 5개의 디펜던시를 한번 살펴보도록 할게요.

먼저 이 테이블에서 프라이머리 키가 어카운트 ID니까 이 어카운트 ID가 동일하면 그 외 나머지 모든 

애트리뷰트에 대한 값들도 다 동일할 거잖아요. 그래서 이런 형태의 펑션널 디펜던시가 존재한다고 볼 수 있고요.

얘를 이제 시각화해서 표현을 하면 이렇게 표현을 할 수 있습니다. 그러니까 이제 functional dependency에서 레프트 핸드

사이드에 해당하는 부분은 이런 식으로 표현을 해주고요. 나머지 라이트 핸드 사이드에 해당하는 애트리뷰트들은 이렇게 화살표로 함께 표시를 해주는 

겁니다. 그래서 이런 식으로 functional dependency를 시각화해서 표현할 수 있고요. 그러면 이 후에 펑션널 디펜던시는 모두 시각화해서 

표현해 보도록 하겠습니다 또 어떤 펑션을 디펜던시가 있냐 지금 이 테이블에는 얘만 키인 것이 아니라

얘도 키라고 했잖아요 그러면은 얘를 통해서도 이 테이블에 있는 튜플들을 유니크하게 식별할 수 있기

때문에 그 말은 무슨 말이냐면 이 두 개의 액트리뷰트에 대해서 값이 동일하다면 나머지 이 액트리뷰트들에

대해서도 값이 동일할 거다 그 말인즉슨 이런 형태의 디펜던스가 존재한다 이렇게 표현할 수 있는 거죠 그 다음에

인플루이 네임 같은 경우에는 당연히 인플로이 ID의 디펜던스가 있을 겁니다 그러니까 인플로이

아이디가 동일하면 당연히 인플루이 네임도 동일하겠죠 그러면은 이 둘 사이에도 이런 형태의

디펜던트가 존재하기 때문에 이런 식으로 시각화해서 표현할 수 있고요. 또 어떤 펑셔널 디펜던스가 있냐면 자 보시면

우리가 아까 등급 얘기를 했었는데요. 국민은행 계좌에는 등급이 스타, 프레스티지, 로얄이 있다라고

했고요. 우리은행 계좌에는 등급이 브론즈, 실버, 골드가 있다고 얘기를 했습니다. 그러면 지금 보시면

국민은행에 있는 등급들의 이름이랑 우리은행에 있는 등급들의 이름이 서로 겹치는 게 없는 거잖아요. 그러니까 무슨 말이냐면 이렇게 계좌에

등급을 보면 아이 계좌가 국민은행 계좌인 건지 우리은행 계좌인 건지 바로 알 수 있다라는 거죠. 그러면

여기서도 functional dependency가 있는 거잖아요. 즉 클래스가 같으면 그 뱅크 네임도 항상 같을 거예요. 그렇기 때문에 얘도 시각화해서 표현을 해주면

클래스가 뱅크 네임을 결정하는 functional dependency가 또 이렇게 존재한다라고 표현해 줄 수 있을 겁니다. 그래서 지금까지 주요 functional dependency를

살펴봤고요. 이제 그러면 본격적으로 노멀라이제이션, 그러니까 정규화를 시작해 보도록 하겠습니다. 아까

앞에서도 설명드렸던 것처럼 처음부터 차근차근 진행한다고 했잖아요. 그래서 1NF부터 진행을 할 건데요. 사실은

이렇게 테이블을 정교하게 되면 키만 놓고 총기화를 진행을 하게 되는데요. 그런데 지금은 정규화를 통해서 어떻게 중복

데이터가 줄어들 수 있는지를 같이 보여드리기 위해서 몇 가지 데이터를 넣은 상태에서 총기화를 진행해 보도록 하겠습니다.

그래서 지금 보시는 것처럼 이렇게 예제로 사용할 만한 데이터를 넣었구요. 현재 상태를 좀 살펴보면 소니와

메쉬는 두 경우에 대해서 계좌 정보를 저장하고 있습니다. 그런데 보시면 지금 소니 같은 경우에는 계좌를 3개를 들고 있는 거잖아요.

그래서 이 서로 다른 계좌 아이디 3개를 들고 있는 거고 그러면 소니는 두 개의 계좌는 우리은행 계좌이고 하나의 계좌는 국민은행 계좌입니다.

그래서 월급을 받을 때마다 세 개 계좌로 나눠 받을 수 있도록 설정을 해 놓은 거예요. 그러면 어떤 비율로 나눠 받을 수 있게

설정을 해 두었냐면 지금 보시면 이 계좌는 0.1, 전체 10분의 1만 받고 그 다음에 이 계좌는 전체

10분의 2만 받고 이 계좌는 전체 10분의 7을 받을 수 있도록 그렇게 월급을 나눠서 받을 수 있도록 설정을

해 놓은 겁니다. 그리고 각 계좌는 이렇게 연동된 카드 아이디가 있는 거고요. 그 다음에 이번에는 매쉬 한번

살펴볼게요 메쉬 같은 경우에는 계좌를 하나만 들고 있어요 그래서 이 계좌로 전체 월급을 다 받겠다 이렇게

설정을 해 놓은 거고요 그런데 이 계좌에 연동된 카드는 두 개가 있는 겁니다 그래서 두 개의 카드 번호가 이 카드 아이디에 저장이

되어 있는 거예요 자 그러면 이제부터 노멀라이제이션을 정말로 시작해 보도록 하겠습니다 그러면 처음부터 차근차근 진행한다고

했잖아요 이 첫 번째 노멀 폼은 뭐냐면 모든 애트리뷰트의 밸류는 반드시 나누어질 수 없는

단일한 값을 가져야 된다는 그런 룰이 있습니다 그런데 지금 보시면요 부분이 이 원앤에프를 위반하고 있어요

왜냐하면 얘는 더 이상 나눠질 수 없는 단일한 값이 아니죠 이렇게 두 개로 나눠질 수 있는 값이 하나의 밸류로 저장이

되어 있는 거잖아요 그러면 얘는 원앤f를 위반하고 있는 거라서 얘를 이제 처리를 해줘야만 다음 단계로 넘어갈 수 있습니다 그러면

처리할 수 있는 방법은 여러 가지가 있지만 지금은 가장 단순하게 이런 식으로 처리를 해줬다고 해볼게요 그러니까 하나의 튜플을 더 만들어서

이렇게 값들은 나눠서 저장할 수 있도록 한 다음에 나머지 액트리뷰트 이렇게 중복이 되도록 저장을 한 거예요 그러면 어쨌든 이 상태는 아까

있었던 원앤f를 위반하는 문제를 해결을 한 거기 때문에 이제 원앤애플을 만족하고 있는 상태입니다 하지만 문제가 있죠 보시면 이렇게

(1부) DB 정규화(normalization)는 DB를 설계하는 공식적인 방법이죠~ 1부에서는 정규화 개념과 정규화 과정의 앞 부분인 1NF, 2NF를 설명합니다 :)

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널


쉬운코드

데이터베이스 정규화 소개 및 1NF 설명

1NF 정규화의 목적: 데이터 중복 및 이상 현상(업데이트, 삭제, 삽입 문제) 최소화

1NF 정규화 과정: 노멀 폼에 따라 데이터를 릴레이션으로 구성

노멀 폼: 정규화를 위해 준수해야 하는 룰들

정규화 과정: 초기 테이블에 노멀 폼 순차 적용

단계적 적용: 앞 단계 만족 시 다음 단계 진행 (예: 3NF 만족 시 1NF, 2NF도 만족)

1NF ~ BCNF: 함수적 종속성과 키로 정의되는 노멀 폼

일반적 정규화 기준: 3NF 도달 시 정규화 완료

실무 정규화 범위: 3NF 또는 BCNF까지 (최대 4NF)

5NF, 6NF 이상은 케이스 발생 가능성 낮고 복잡하며 학술적 분석 경향이 강함

본 영상 설명 범위: 1NF ~ BCNF (실무 적용 빈도 고려)

임직원 월급 계좌 정보 테이블 예시 및 키 개념 설명

테이블 구성: 임직원 월급 계좌 정보 관리 (국민/우리은행, 월급 분배 비율, 계좌 등급, 카드 정보)

슈퍼키: 테이블에서 튜플을 유니크하게 식별하는 애트리뷰트 집합

캔디데이트 키(키): 어떤 애트리뷰트도 제거하면 유니크 식별 불가능한 슈퍼키

예시 테이블 키: account id (단일 애트리뷰트 키), {bank name, account number} (다중 애트리뷰트 키)

프라이머리 키: 유니크 튜플 식별을 위해 선택된 캔디데이트 키 (본 예시: account id)

함수적 종속성(Functional Dependency) 분석

프라이머리 키(account ID) 기반 함수적 종속성: account ID 동일 시 다른 애트리뷰트 값도 동일

{bank name, account number} 키 기반 함수적 종속성: 키 값 동일 시 다른 애트리뷰트 값도 동일

employee ID와 employee name 간 함수적 종속성: employee ID 동일 시 employee name도 동일

계좌 등급(class)과 은행 이름(bank name) 간 함수적 종속성: class 동일 시 bank name도 동일

정규화(Normalization) 과정 시작 및 1NF 적용

정규화 과정: 1NF부터 순차적으로 진행

데이터 추가: 중복 데이터 발생 확인을 위한 예시 데이터 추가

1NF 규칙: 모든 애트리뷰트 값은 나누어질 수 없는 단일 값

1NF 위반 사항: 월급 분배 비율(ratio) 애트리뷰트가 단일 값이 아님

1NF 위반 해결: 튜플 추가 및 값 분리, 중복 데이터 발생

2NF 적용 및 중복 데이터 문제 해결

중복 데이터 원인 분석: 키 확인 및 non-prime attribute 파악

non-prime attribute: 키에 속하지 않는 attribute (class, ratio, employee ID)

키 기준 함수적 종속성 분석: non-prime attribute의 부분적 종속성(partial dependency) 확인

2NF 규칙: 모든 non-prime attribute가 모든 키에 대해 완전 함수적 종속(fully functional dependency)

2NF 위반 해결: 카드 정보 테이블 분리, 중복 데이터 제거

2NF 만족 확인: 두 테이블 모두 non-prime attribute가 모든 키에 대해 fully functional dependency 만족

3NF 확인: 남은 중복 데이터 확인 및 추가 정규화 여부 판단