데이터 모델링

---

데이터 모델링 : 현실 셰계의 데이터를 저장하고 활용하기 위해 설계를 수행하는 과정
어디에 어떤 데이터를 저장할지 고민하고 설계하는 절차

• 백엔드 개발자 관점 : 우리가 프로젝트를 할때 ERD를 짜는데 그게 이거임

• 특징

• 단순화

• 추상화

• 명확화

---

단순화

단순화는 말 그대로 데이터를 단순하게 표현하는것

예를 들어 요리를 하고 배달하는 과정은 냄비 준비하고 물 넣고 같이 과정이 많지만
조리중, 배달중, 배달완료로 단순하게 표현하는것

추상화

추상화는 데이터의 특징만 추려 추상적으로 표현하는것

예를 들어 현실의 사람에게서 '키, 몸무게'는 버리고 '주소, 연락처'만 뽑아 회원으로 만드는 것

명확화

단순화하고 추상화한 데이터를 사람들이 이해하게 명확하게 만드는것

연락처를 받는데 어떤 사람은 010-XXXX-XXXX 이런식으로 받고 어떤 사람은 010XXXXXXXX 이런식으로 받으니까
전화번호는 010-XXXX-XXXX 이런식으로 받겠다고 명확하게 정하는것

---

데이터 모델링의 관점

모델링에는 여러 관점이 존재함

• 데이터 관점 모델링
• 프로세스 관점 모델링
• 상관 관점 모델링

---

1. 데이터 관점

어떤 데이터가 필요한지를 중심으로 모델링합니다.

화원가입 하는데 어떤(What) 데이터가 필요한지

• 회원 ID
• 이름
• 비밀번호

이처럼 어떤 데이터가 필요한지의 관점에 따라 모델링 하는게 데이터 관점 모델링

2. 프로세스 관점 모델링

업무가 어떻게(How) 진행되는지 관점에서 모델링

1. 회원가입 정보 입력
2. 회원가입 정보를 제대로 입력했으면 회원가입 완료
3. 로그인 창으로 이동

이렇게 데이터가 어떤식으로 흘러가는지를 관점에서 모델링한게 프로세스 관점 모델링

3. 상관 관점 모델링

상관 관점은 업무(How)에 따라 데이터(What)와 어떻게 작용하는지 관점에서 모델링 한 것

쉽게 말하면 "어떤 업무(Process)를 할 때, 어떤 데이터(Data)를 CRUD 하는가?"

• "회원가입"이라는 업무 흐름이 발생하면 회원 관련 데이터가 추가(CREATE)됩니다.
• 회원 탈퇴 업무 흐름이 발생하면 회원 관련 데이터가 삭제(DELETE)됩니다.
• 회원 정보 수정 업무 흐름이 발생하면 회원 관련 데이터가 수정(UPDATE)됩니다.
  이러한 관계는 CRUD 매트릭스 형태로 분석해 표현할 수 있습니다.
  

데이터 관점: 테이블 구조 짜기 ($\rightarrow$ ERD)
프로세스 관점: 비즈니스 로직/알고리즘 짜기 ($\rightarrow$ DFD)
상관 관점: 어떤 로직에서 어떤 테이블을 건드리는지 매핑하기 ($\rightarrow$ CRUD 매트릭스)

---

데이터 모델링의 중요성

집을 지을때 설계도를 잘 지어놓아야한다.
그렇지 않으면 사람마다 생각하는게 달라 다 다른집을 만들테니

데이터 모델링도 집과 똑같다,데이터 모델링을 잘해놓지 않으면 기능이 추가되고 요구사항이 바뀔때 시스템 전체를 수정해야한 상황이 생길수도 있다.
그러니 데이터 구조를 명확히 정의하고 체계적으로 설계하는 데이터 모델링 과정이 반드시 필요하다.

데이터 모델링의 중요성 3관점

1. 파급효과

설계 없이 개발을 하면
1. 요구사항이 바뀌거나
2. 기능이 추가 되었을 때

→ 구조 전체를 수정해야하는 파급효과가 발생할수도 있다.

그러나 모델링을 통해 구조를 잘 설계해논다면 변경사항이 생겨도 영향 범위를 최소화 할수 있다.

2. 복잡한 정보 요구 사항의 간결화

요구사항을 글로만 쓰면 사람마다 해석하는게 달라 헷갈릴수 있으니까
요구 사항을 시각화하여 협업의 기준이 되는 설계도를 제공하는것

3. 데이터 품질(중복, 비유연성, 비일관성)

데이터 모델링을 제대로 하지 않으면 데이터의 품질이 떨어진다.

데이터의 품질이 떨어지는 이유 3가지

1. 중복

동일한 데이터가 여러 저장소에 관리하며 데이터가 중복되면 데이터 품질이 떨어진다.

1. 나쁜 데이터 모델링 (데이터 중복)

회원 이메일이 User와 Order 테이블에 각각 저장된 경우

• User 테이블: email: chulsoo@email.com
• Order 테이블: user_email: chulsoo@email.com

2. 문제 발생 (데이터 불일치)

회원이 이메일을 chulsoo2@email.com으로 바꿨을 때, User 테이블만 수정하고 Order 테이블을 깜빡하고 안 고치면?

• User 테이블: chulsoo2@email.com (새 이메일)
• Order 테이블: chulsoo@email.com (옛날 이메일)

결론: 똑같은 사람인데 테이블마다 데이터가 달라지는 '데이터 불일치(일관성 깨짐)'가 발생하며, 이로 인해 데이터 품질이 떨어집니다.

2. 비유연성

비유연성이란? 데이터와 프로세스 설계가 너무 긴밀하게 연관되어 업무 변화나 새로운 요구사항에 쉽게 대응하지 못하는 상황

나쁜 데이터 모델링 (비유연함)

주문 테이블에 '신용카드' 전용 컬럼을 직접 넣어둔 경우

• Order 테이블: id, product, card_number
  문제: 나중에 '카카오페이' 결제 기능이 추가되면 기존 테이블 구조를 대대적으로 수정해야 하며, 이로 인해 기존 백엔드 코드에도 에러가 발생함

좋은 데이터 모델링 (유연함)

주문 데이터와 결제 데이터를 분리하여 설계

• Order 테이블: id, product
• Payment 테이블: id, order_id, pay_type (카드/페이 구분)

해결: 새로운 결제 수단이 추가되더라도 주문 테이블은 건드릴 필요 없이 결제 테이블의 종류만 늘리면 되므로 쉽게 대처 가능

비일관성

같은 상황인데 데이터를 다르게 저장하는것을 말한다

예를 들어 똑같이 이사를 가는데 A경우는 주소가 변경되고 기록에 전 주소가 저장 되지만
B경우에는 이사를 가도 전 주소가 저장되지 않는다.

-> 이러면 데이터가 일관되지 않아 신뢰할수 없다
같은 업무 흐름이 항상 동일하게 적용되도록 설계되어야한다.

스키마

외부 스키마: 개발자/사용자가 보는 각자의 화면(일부 관점)

개념 스키마: DB 전체를 통합한 전체 논리 구조(설계자 관점)

내부 스키마: 디스크에 저장되는 물리적 저장 구조(하드웨어 관점)

데이터 독립성

하위 스키마가 변경되어도 상위 스키마가 영향을 받지 않는 특성 (독립성을 유지를 위해 스키마 간 '매핑/사상'을 이용함)

• 논리적 독립성 (개념 $\leftrightarrow$ 외부): 개념 스키마가 변경되어도 외부 스키마(사용자/개발자 관점)는 영향 없음
  • 핵심: 테이블 구조가 바뀌어도 백엔드 응용 프로그램 코드는 수정할 필요가 없음
• 물리적 독립성 (내부 $\leftrightarrow$ 개념): 내부 스키마(저장 장치 관점)가 변경되어도 개념 스키마(전체 논리 구조)는 영향 없음
  • 핵심: 성능 향상을 위해 인덱스를 추가하거나 하드웨어를 바꿔도 테이블 구조와 쿼리문은 그대로 유지됨

도메인을 정의해 두면, 엉뚱한 데이터가 들어오는 걸 막고(유효성), 여러 컬럼의 데이터 규칙을 똑같이 통일(일관성) 시킬 수 있다

정규화의 정규형

1. 비정규형

• 아무 정규화도 안된 상태

2. 1차 정규형(1NF)

• 1차 정규화 도메인 원자성을 확보하는것

3. 2차 정규형(2NF)

• 부분 종속성을 제거하는 것

4. 3차 정규형(3NF)

• 이행 종속성을 제거하는 것

5. 보이스코드 정규형(BCNF)

• BCNF 정규화를 진행해야함 , 결정자 모두 후보키여야하는 것

6. 4차 정규형(4NF)

• 다치 종속 제거 하는 것

7. 5차 정규형(5NF)

• 조인 종속 제거하는 것

정규형 단계	정규화 작업 (핵심 목표)	제거 대상 및 조건	백엔드 관점 한 줄 요약
비정규형	정규화 이전 원본 상태	초기 데이터 구조의 모든 중복	엑셀 시트 하나에 막 쑤셔 넣은 상태
제1정규형 (1NF)	도메인 원자성 확보	컬럼 내 다중값 (원자성 위배)	한 칸에 쉼표(,)로 데이터 여러 개 넣지 마라
제2정규형 (2NF)	부분 함수 종속성 제거	복합키(PK) 일부에만 종속되는 컬럼	기본키가 복합키 일 때, 키 일부에만 묶인 컬럼 쪼개라
제3정규형 (3NF)	이행적 함수 종속성 제거	일반 컬럼 간의 종속 관계 ($A \rightarrow B \rightarrow C$)	일반 컬럼끼리 원인-결과가 되는 징검다리 구조 쪼개라
BCNF	결정자 고도화	결정자이면서 후보키가 아닌 것	모든 결정자가 후보키(Candidate Key)가 되도록 강제
제4정규형 (4NF)	다치 종속 제거	다중값 종속성 ($A \rightarrow\rightarrow B$)	하나의 키에 여러 독립적인 다중값이 매핑되는 구조 분리
제5정규형 (5NF)	조인 종속 제거	조인 시 데이터 왜곡 발생 구조	무손실 분해를 통해 조인했을 때 원래 데이터로 복원 보장

---

💡 실무 및 면접 팁 (Cheatsheet)

• 실무에서는 제3정규형 또는 BCNF까지만 제대로 완성해도 대부분의 이상 현상(Anomaly)을 해결할 수 있습니다.
• 4차, 5차 정규형은 이론적인 영역에 가까우며, 실무에서는 쿼리 성능 향상을 위해 오히려 역정규화(반정규화)를 고민하는 경우가 많습니다.

다치 종속

• 한 테이블에 서로 아무 상관 없는 List 형태의 데이터 2종류가 들어가서 모든 조합을 다 만들어내며 괴롭히는 현상.

• 4차 정규화: 그 List들을 각각 별도의 테이블로 쪼개서 독립시키는 것.

구분	완전 함수 종속 (정상)	부분 함수 종속 (이상 현상 유발)
의존 상태	기본키 구성원 전원의 힘이 필요함	기본키 구성원 중 일부 힘에만 굴복함
수식 표현	$(학번, 과목코드) \rightarrow 성적$	$과목코드 \rightarrow 강의실$ (학번은 왕따)
2차 정규화 조치	그대로 테이블에 유지	부분 종속되는 컬럼을 떼어내서 새 테이블로 분리