알아두면 쓸데있는 데이터 모델링 (1) 정규화
데이터 모델링, 이번 기회에 제대로 공부하고 싶다면!
데이터 모델링, SQL 성능 최적화 뿐만 아니라 LTR 분석 등 다양한 분석 프레임워크까지 배울 수 있는 SQL 마스터반 커리큘럼을 살펴보세요. 쿠팡, 리디, 잡플래닛 출신 데이터 분석가들이 실무에 꼭 필요한 내용만 골라 담았어요.
이 글은 나른한 오후에 쓰고 있습니다. 잠을 좀 쫓아보려고 커피를 한 잔 사 왔어요. 아래는 커피 결제 영수증입니다.
IMG_3741 2.jpg
이 영수증 데이터가 데이터베이스에서 어떻게 관리되고 있을지 갑자기 궁금해졌어요 🤔 (하나도 궁금하지 않다고요? 데이터를 사랑하는 여러분이 그럴 리가요!) 그래서 <영수증>이라는 테이블을 만들어 보았습니다.
Table <영수증>
이렇게 하나의 테이블로 모든 데이터를 관리한다면, 어떤 문제점이 생길 수 있을까요? 
만약 매장의 주소가 바뀌면 모든 데이터의 주소 데이터를 업데이트해야 합니다. 매장 이름이나, 전화번호도 마찬가지입니다. 또한 매장의 주소 같은 정보가 중복으로 저장되어 저장 공간도 많이 차지합니다. 
주문이 한 번도 발생하지 않은 메뉴 데이터를 관리할 수 없습니다. 같은 원리로 레몬 쌀 파이 데이터를 삭제하면 레몬 쌀 파이라는 메뉴도 함께 삭제됩니다.
한 번 주문할 때 메뉴는 최대 2개까지만 가능합니다. 
이렇게 설계가 잘못된 테이블에 데이터를 담았을 때 여러 가지 문제들이 생길 수 있습니다. 사실 이런 문제는 데이터 간의 종속 관계에 따라 테이블을 잘 정리해 주면 대부분 해결할 수 있습니다. 이걸 어떻게 하는 것이 최적인가에 대한 방법론이 바로 정규화 이론입니다. 아직은 ‘종속’, ‘테이블의 관계’라는 말이 어색할 텐데요. 정규화 이론에 관해서 얘기하면서 차근차근 풀어나가 보겠습니다.
정규화 이론이라고 하니 좀 어렵고 딱딱해 보이지만, 상식 선상에서 모두 이해할 수 있습니다. 혹시 글을 보다가 막히는 부분이 있으면 당황하지 말고 ‘상식적으로 다시 생각해 보자 💭’는 마음가짐으로 내용을 곱씹어 보시면 좋겠어요. 저한테는 이런 마음가짐이 모델링 공부를 놓지 않는 데 도움이 많이 됐습니다.
제1정규화
아래와 같이 카페의 정보를 관리하는 테이블이 있다고 생각해 봅시다. 메뉴라는 컬럼에 값이 여러 개가 들어가 있습니다. 한 카페에서 여러 메뉴를 팔 수 있기 때문입니다. 제1정규화 원칙은 이런 상황에서 하나의 값만 가져야 한다는 것입니다.
Table <카페>
테이블 모양이 약간 다르지만, 아래의 경우도 마찬가지입니다.
Table <카페>
이렇게 하나의 셀에 여러 개의 값이 들어간 경우 또는 개념적으로 중복되는 컬럼이 있는 경우에는 아래와 같이 별도의 테이블로 분리해야 합니다.
Table <메뉴>
이게 제1정규화입니다! 어렵지 않죠? 
카페 정보를 관리하는 것보다 좀 더 일반적인 예시는 주문 테이블일 거예요. 일반적으로 하나의 주문에 여러 종류의 상품이 속할 수 있으므로 주문과 주문한 상품은 각각 <주문>, <주문 상세> 테이블로 분리하여 관리합니다. 아래와 같은 식으로요.
Table <주문>
Table <주문 상세>
제2정규화
제2정규화에 관해 얘기하기 전에, 한 가지 용어를 정리하고 넘어가겠습니다. 아마 이 글을 보시는 분들은 아래 테이블에 있는 카페 ID, 상호, 연락처를 컬럼(Column)이라고 부르는 데 익숙할 겁니다.
Table <카페>
데이터 모델링 세계에서는 이것들을 데이터의 ‘속성(Attribute)’이라고 부릅니다. 데이터를 설명하는 요소라는 뜻이지요. 2차원의 테이블에 이 속성을 컬럼으로 표시하기 때문에 ‘컬럼’, ‘속성’, ‘어트리뷰트’라는 단어가 혼재되어 사용되는데요. 저는 이 글에서 앞으로 ‘속성’이라고 부르겠습니다.
이번에는 아래와 같은 테이블이 있다고 생각해 보겠습니다. 어떤 상품을 주문했는지 정보를 저장하는 주문 상세 테이블입니다. 
Table <주문 상세>
각 데이터를 고유하게 식별할 수 있는 최소한의 속성을 후보 키(Candidate Key)라고 부르는데요. 이 테이블에서 후보 키는 주문 번호와 상품 코드의 조합입니다. 보통은 행을 대표하는 하나의 속성이 후보 키가 되는 경우(예. <주문> 테이블의 주문 번호)가 많은데, 종종 이렇게 두 속성의 조합이 후보 키가 되는 경우도 있습니다.
Table <주문 상세>의 속성
주문 번호 (후보 키)
상품 코드 (후보 키)
상품명
상품 가격
주문 수량
제2정규화는 후보 키가 아닌 속성(상품명, 상품 가격, 주문 수량)이 후보 키 전체(주문 번호, 상품 코드)에 종속되어야 한다는 겁니다. 말이 어렵죠? 차근차근 뜯어볼게요.
여기에서 ‘종속’은 직관적으로 이해할 수 있는 개념입니다. Y가 X에 종속적이라는 말은 X가 Y를 결정한다는 말과 같은 말입니다. 예를 들어, 상품 코드를 알면 상품명과 상품 가격을 알 수 있죠. 이럴 때, ‘상품명과 상품 가격이 상품 코드에 종속적이다’라고 하고 아래처럼 표현합니다.
(상품 코드) → (상품명, 상품 가격)
다시 제2정규화 얘기로 돌아와 볼까요? 후보 키가 아닌 속성(상품명, 상품 가격, 주문 수량)이 후보 키 전체(주문 번호, 상품 코드)에 종속되어야 한다고 얘기했었습니다. 다른 말로 하면, 일부 후보 키 속성에만 종속적인 속성이 있으면 제2정규화 원칙에 위배된다는 뜻입니다.
주문 수량의 경우, 주문 번호와 상품 코드가 함께 주문 수량이라는 값을 결정하므로 제2정규화 원칙에 부합합니다. 많은 주문 상세 데이터 중에 어떤 주문에서(주문 번호), 어떤 상품을(상품 코드) 구매한 데이터를 보겠다고 특정하면 몇 개를 샀는지(주문 수량)도 알 수 있게 되니까요. 주문 번호만 알아서는 주문 수량을 특정할 수 없고, 상품 코드만 알아서도 주문 수량을 특정할 수 없습니다.
(주문 번호, 상품 코드) → (주문 수량)
하지만 상품명과 상품 가격은 주문 번호라는 속성과는 관련이 없고, 상품 코드라는 속성에만 종속되어 있습니다. 주문에 따라서 상품 이름이나 가격이 달라지지는 않으니까요.
(상품 코드) → (상품명, 상품 가격)
이는 후보 키가 아닌 속성이 후보 키 전체에 종속되어야 한다는 제2정규화 원칙을 위배합니다. 이렇게 일부 후보 키 속성에만 종속적인 속성(상품명, 상품 가격)은 별도 테이블로 분리해야 합니다. 제2정규화 원칙은 이렇게 후보 키가 2개 이상인 경우에 꼭 생각해 봐야 하는 원칙입니다. ‘혹시 일부 후보 키에만 종속적인 속성이 있나?’ 살펴봐 주세요.
Table <주문 상세>
Table <상품>
제3정규화
이번에는 아래와 같은 데이터를 가정해 보겠습니다. 온라인 쇼핑몰의 주문 데이터입니다.
Table <주문>
지금까지 배운 것을 이용해 <주문> 테이블의 속성들을 적어보겠습니다.
Table <주문>의 속성
주문 번호 (후보 키)
주문 날짜
회원 번호
이름
국가
테이블에서 후보 키가 아닌 속성들은 모두 후보 키에 종속되어야 합니다. 그런데 겉으로는 그런것으로 보이지만, 실제로는 후보 키가 아닌 다른 일반 속성에 종속된 속성들이 있을 수 있습니다. 이 예에서는 이름, 국가가 그렇습니다. 이름과 국가는 테이블의 후보 키인 주문 번호에 종속된 것이 아니라, 회원 번호라는 일반 속성에 종속되어 있습니다.
(회원 번호) → (이름, 국가)
이를 별도의 테이블로 분리하는 것이 제3정규화입니다. 정규화하고 나면 아래와 같이 <회원>이라는 테이블이 새로 생깁니다.
Table <주문>
Table <회원>
마무리
사실 제1~3정규화 원칙 이외에도 몇 가지가 더 있는데요. 실무에서는 여기까지만 알아도 충분합니다. 
정규화 이론은 데이터 모델링의 꽃이라고 불릴 만큼 핵심적인 이론입니다. 그런데 상식 선상에서 다 이해가 되는 내용이었죠. 이론을 모르고도 정규화를 잘해서 모델링을 하고 있던 분도 있을 것입니다. 
사실, 관계형 데이터 모델은 집합론(Set theory)의 관계형 이론(Relational theory)이라는 수학적인 이론을 바탕으로 합니다. ‘관계형’이라는 이름 자체가 이 수학 이론의 이름에서 왔습니다. 그러다 보니, 수학적으로 설명해 놓은 문서들이 많습니다. 처음 배우는 입장으로는 참 난감하죠. 저 역시 그렇게 느꼈습니다. 하지만 알고 나니 꼭 엄밀한 수학 용어로 설명하지 않아도 정규화의 본질을 이해하는 데에는 문제가 없겠더라고요. 우리가 이 이론을 연구하는 사람들도 아니고, 실무에서 필요한 정도로 이해하고 있으면 되는 거잖아요? 그래서 이 글은 정규화 이론을 쉽게 이해하는 데에 초점을 맞추어 써보았습니다. 혹시 엄밀하지 못한 용어 사용에 마음 한구석이 불편해진 분들이 계신다면 심심한 사과의 말씀을 드립니다. 😅
이번 글에서 ‘후보 키(Candidate Key)’라는 용어를 많이 썼는데요. 무언가의 후보가 된다는 뜻이겠죠? 데이터 모델링 세계에는 후보 키 이외에도 슈퍼 키(Super Key), 기본 키(Primary Key, PK), 대체 키(Alternate Key), 외래 키(Foreign Key, FK) 등 다양한 Key가 있습니다. 여러 가지 종류의 Key를 이해하고 나면 데이터 모델링을 하는 시야가 한층 넓어질 거예요. 이 중에서 PK, FK는 아마 ERD에서도 자주 보셨을 겁니다. 다음 글에서는 다양한 종류의 Key에 관해서 이야기를 해보겠습니다.


대표 이미지

예상 읽기 시간

공개 가능

제목

요약

전환 텍스트

작성일

conversion_type

시리즈 내 순서

conversion_text

멤버 전용

글쓴이

시리즈

상단 노출

전환 유형

1정규형부터 3정규형까지, 데이터 모델링의 꽃인 정규화 이론에 대해서 쉽게 배워봐요.

알아두면 쓸데있는 데이터 모델링 (1) 정규화

ERD에서 자주 본 PK, FK의 정확한 의미를 알아봅시다.

알아두면 쓸데있는 데이터 모델링 (2) 여러 종류의 Key 이해하기 (feat. PK, FK의 정확한 의미)

ERD에서 관계 표기(Crow’s foot)를 이해하기 어려웠다면 이 글에 있는 꿀팁을 참고해보세요.

알아두면 쓸데있는 데이터 모델링 (3) ER 모델의 구성 요소 - 엔티티, 속성, 관계

ERD를 어떻게 읽어야 하는지 모른다면, 이번 글에서 그 방법을 익혀봅시다.

알아두면 쓸데있는 데이터 모델링 (4) ERD 읽어보기

엔티티를 잘 정의하기 위해서는 본질을 꿰뚫어보는 눈이 필요합니다

알아두면 쓸데있는 데이터 모델링 (5) 엔티티 톺아보기

데이터 표준화, 식별자, 유연함을 가진 속성 모델링

알아두면 쓸데있는 데이터 모델링 (6) 속성 톺아보기

참조 무결성 제약은 오류 데이터의 진입을 막는데 굉장히 효과적인 방법입니다.

알아두면 쓸데있는 데이터 모델링 (7) 관계 톺아보기 (feat. 데이터 무결성)

데이터 모델링의 종류를 알아보고 ERD를 직접 그려봅시다.

알아두면 쓸데있는 데이터 모델링 (1) 정규화

Contents

알아두면 쓸데있는 데이터 모델링 모아보기

함께 읽어보면 좋은 글

인덱스 타입: B-Tree, Hash

SQL 자격증, 데이터 분석 능력은 어필할 수 없어요

SQL 코딩테스트, 문법보다는 생각의 흐름이 중요해요

데이터 분석 소식을
한 달에 한 번 받아보세요

알아두면 쓸데있는 데이터 모델링 (1) 정규화

Contents

알아두면 쓸데있는 데이터 모델링 모아보기

함께 읽어보면 좋은 글

인덱스 타입: B-Tree, Hash

SQL 자격증, 데이터 분석 능력은 어필할 수 없어요

SQL 코딩테스트, 문법보다는 생각의 흐름이 중요해요

데이터 분석 소식을 한 달에 한 번 받아보세요

데이터 분석 소식을
한 달에 한 번 받아보세요