[ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

Data-Forge : 데이터로 세상 이해해보기.·2025년 7월 22일

DB : SQL(RDBMS,NoSQL,VectorDB) 이론 공부.

목록 보기

17/19

[ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

▽ [ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

목  차

1. 요구사항 분석

2. 개체와 속성을 추출

3. 개체 간의 관계를 추출

4. 만들어진 개체-속성, 개체-관계를 바탕으로 개념적 설계(ERD)작성하기

5. 논리적 설계

6. 정규화

7. 물리적 설계.

1. 요구사항 분석.

DB 설계에 앞서서, 내가 구현해야할 시스템이 어떻게 처리되는지 정확히 파악해야 함!

🔍 Why: 왜 중요한가?

DB 모델링은 결국 "데이터 기반의 시스템 설계".
잘못된 요구분석 -> 불완전한 모델 -> 서비스 로직 왜곡 -> 빠르게 망함.

✅ 개념 정의.

"요구사항 분석" 은 시스템이 해결해야 할 "비즈니스 문제나 목적"을 파악하는 단계.
시스템이 필요한 이유, 목적, 핵심 프로세스를 정리하는 단계
사용자/운영자/관리자 등 이해관계자별 사용 목적 파악.
이해관계자(고객, 기획자, 마케터, 관리자 등등)의 니즈와 사용 흐름, 주요 데이터 항목, 기능 등을 명확히 해야 함. !
개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동
사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
사용자의 요구를 정확하게 추출하여 목표를 정함.

🎯 What: 무엇을 분석하는가?

업무의 본질적 흐름
- "어떤 행위" 와 "주체"들이 있는가??
데이터의 라이프사이클
- 데이터는 어디서 생성되고, 수정되고, 언제 삭제/비활성 되는가??
분석 단위
- 개체(Event/ Entity)
- 행위(Activity)
- 관계(Relationship)

⚙️ How: 분석 방법

Use Case 흐름, 유저 여정(시나리오 기반), BPMN, C4 Model
Excel 로 Data Matrix 구성(화면-데이터 Mapping)
이해관계자와의 Q&A 문서화

💡 실무 적용

기획서, 와이어프레임, 화면정의서, API 명세서를 바탕으로 "데이터 흐름" 재해석
주요 명사(개체 후보), 동사(행위 또는 상태), 시제(이력) 중심으로 분해.

⚙️ 의사결정 기준

항목	질문
데이터 소유권	이 데이터는 누가 최초 생성/수정/삭제하는가?
발생 시점	동시성 문제가 발생할 가능성은?
이력 필요성	변경 이력 추적이 필요한가? (변경 추적 테이블 분리?)
추상화 레벨	화면 중심이 아니라 도메인 중심으로 재정의할 수 있는가?

💡 실무 Tip

"이 데이터는 누가 생성하고 누가 관리하는가??" 이 질문을 Key로 업무 흐름을 정리
기획 무너 or 와이어프레임에서 CRUD 주체 분석.
API 계약서(Swagger, OpenAPI)가 있다면, Request/Response 구조 도출 가능

요구사항의 종류

요구사항 - 기능적 요구사항.

시스템이 무엇을 하는지, 어떤 기능을 하는지 등 기능의 수행과 관련된 요구사항
시스템의 입력과 출력으로 무엇이 포함되어야 하는지에 대한 사항
시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
시스템이 반드시 수행해야 하는 기능
사용자가 시스템을 통해 제공받기를 원하는 기능

요구사항 - 비기능적 요구사항.

품질이나 제약사항과 관련된 요구사항
시스템 장비 구성 요구사항
성능 요구사항
인터페이스 요구사항
데이터를 구축하기 위해 필요한 요구사항
테스트, 보안을 위한 요구사항
품질 요구사항: 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등
프로젝트 관리 요구사항
프로젝트 자원 요구사항

2. 개체(Entity)와 속성(Attribute) 도출 (대부분 명사)

✅ 개념 정의.

개체(Entity) : 시스템이 관리해야 할 명확한 실체 ( 고객, 주문, 상품 등)
속성(Attribute) : 해당 개체의 고유한 정보(이름, 연락처 등)

🔍 Why

DB의 테이블은 결국 '관리 대상 실체(Entity)'를 테이블로 전환한 것이기 때문.

🎯 What

개체(엔티티: Entity) : 고객, 주문, 상품, 결제 등 "존재하고 식별 가능한 것들"
- 엔티티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당
- 엔티티는 업무상 관리가 필요한 관심사에 해당
- 엔티티는 저장이 되기 위한 어떤 것(Thing).
속성(Attribute) : 개체를 설명하는 데이터(ex: 상품여, 수량, 단가 등)

⚙️ How

업무 분해 -> 명사 추출 -> 유사 항목 정제 -> 테이블 후보군으로 변환
속성은 화면의 필드(입력/출력 항목)와 메시지 구조 참고

💡 실무 적용

화면 필드, API 요청/응답, 로그 데이터를 바탕으로 개체 및 속성 도출
속성의 '종류'
- 식별자(PK 후보)
- 비즈니스 속성
- 상태값
- 참조 키(FK 후보)
- 이력값(등록일, 수정일 등)

⚙️ 의사결정 기준

판단 기준	설계 의사결정
속성은 원자값인가?	문자열 배열 형태로 저장 시 → 별도 테이블로 분해
수정 빈도 높은 속성	물리 분리 고려 (e.g. `user_profile`, `user_security`)
사용량 많은 속성	캐싱 고려, Redis 등과의 연동성도 고려

3. 개체 간의 관계를 추출(대부분 동사)

✅ 개념 정의.

관계(Relationship) : 두 개 이상의 개체 간의 연결
관계의 종류 : { 1:1, 1:N , N:M }

💡 실무 적용.

N:M 관계는 대부분 '교차 테이블'로 풀어서 다대다 매핑
관계는 정적인 구조가 아니라 '업무 흐름상 동적인 의미'를 가짐.

⚙️ 의사결정 기준

관계 유형	고려사항
1:1	두 테이블을 나눠야 하는가? 하나로 합쳐야 하는가? → 접근 빈도 & 보안이 판단 기준
1\:N	자식 테이블의 정합성 → FK 및 ON DELETE 전략
N\:M	관계가 단순 연결인가? 추가 메타가 있는가? → 주문-상품 관계는 단순 관계가 아님

4. 만들어진 개체-속성, 개체-관계를 바탕으로 개념적 설계(ERD)작성하기

✅ 개념 정의.

요구사항을 기반으로 개념적 모델을 구축.
개념적 모델은 엔티티와 엔티티 간의 관계를 나타내는 엔티티-관계다이어그램(ERD)으로 표현.
엔티티 간의 관계에 초점을 맞추고, 엔티티의 속성은 일반적으로 고려하지 않음.
ERD란
- 개체-속성-관계를 시각적으로 표현한 다이어그램.
ERD를 통해 구조를 명확히 공유
예를 들어, "고객(Customer)"-"주문(Order)" 라는 엔티티 사이의 관계를 ERD로 표현.

💡 실무 적용.

ERD 도구 : dbdiagram.io, ERDCloud, MySQL Workbench, Draw.io 등
Naming Convention 적용:
- snake_case
- 복수형 테이블명 : users, orders
- 관계명에는 명확한 의미를 부여 : user_addresses vs user_shipping_addresses

⚙️ 의사결정 기준

항목	설계 지침
관계 방향성	단방향 or 양방향 의존성 → ERD에 화살표로 명확히 표현
설계 명확도	ERD는 비기술자도 이해 가능해야 한다
변경 이력	ERD는 버전 관리가 되어야 한다 → Git 또는 ERD export

5. 논리적 설계 (DBMS 독립적)

✅ 개념 정의.

테이블 구조, 속성 타입, 제약조건 등을 정리 (아직 DBMS에 종속되지 않음)
개념적 모델을 바탕으로 논리적 모델을 개발(설계)합니다.
논리적 모델은 개념적 모델을 '데이터베이스 시스템'의 특정 구현 방식에 맞게 변환한 것.
엔티티를 테이블로 변환하고, 속성을 열(Column)로 매필.
관계를 외래 키(FK)로 표현하여 테이블 간의 관계를 설정.

💡 실무 적용.

테이블 정의서 작성
타입 정의 : String, Number, Date, Boolean 수준
제약 조건:
- NOT NULL
- UNIQUE
- DEFAULT
- CHECK

⚙️ 의사결정 기준

항목	판단 기준
제약조건 전략	FK를 실무에서 사용할 것인가? (관계 명시 vs 성능 저하)
ID 전략	UUID, AUTO_INCREMENT, Snowflake 중 선택 이유?
정합성 책임	DB vs 어플리케이션 레벨 정합성 유지 판단

6. 물리적 설계 (DBMS 종속)

✅ 개념 정의.

실제 DBMS에 맞게 테이블, 인덱스, 파티션, 스토리지 구조 등까지 반영
논리적 모델을 기반으로 물리적 모델을 설계
물리적 모델은 실제 데이터베이스 시스템에서 사용될 구조를 정의
테이블 간의 관계, 인덱스, 제약 조건 등을 정의
각 열의 데이터 유형, 크기, 제약 조건 등을 명시.

⚙️ 의사결정 기준.

항목	고려 사항
인덱스 설계	WHERE 절 조건 분석 → 복합 인덱스 설계 (선행 컬럼 고려)
파티셔닝	월별 파티션? ID 범위 파티션? 로그성 테이블 관리 필요
이중화	Master-Slave 구성 고려 시 Key ID 충돌 방지 전략 필요
마이그레이션	Flyway/Liquibase 등으로 테이블 버전 관리 필수

7. 정규화

✅ 개념 정의.

데이터 중복을 줄이고 무결성을 높이기 위한 단계적 분해.
데이터베이스의 성능, 일관성 및 효율성을 개선하기 위해 정규화를 수행
정규화는 중복 데이터를 제거하고 데이터를 논리적으로 구조화하는 과정
주로 엔티티의 함수적 종속성을 분석하여 정규화 수준을 결정하고, 테이블을 분리하거나 조정.

단계	의미
1NF	컬럼이 원자값
2NF	부분 종속 제거
3NF	이행 종속 제거

⚙️ 의사결정 기준.

항목	기준
조회 성능	너무 많은 JOIN? → 비정규화 고려
이력 관리	변동 가능한 속성은 별도 이력 테이블로 분리
데이터 압축	수천만 Row에서 정규화 vs 압축 vs 컬럼 분할 전략 필요

⚙️ 반정규화

성능 향상을 위해 반정규화를 고려할 수 있음
반정규화는 정규화된 데이터베이스를 조정하여 읽기 성능을 향상시키는 과정
데이터 중복이 증가할 수 있으므로 주의가 필요.

8. 물리적 구현

데이터 모델을 실제 데이터베이스 시스템에 구현.
테이블을 생성하고 열의 데이터 유형, 인덱스, 제약 조건등을 설정
데이터베이스 관리 시스템(DBMS)의 SQL 문을 사용하여 스키마를 생성.

Data-Forge : 데이터로 세상 이해해보기.

Roll with the punches

이전 포스트

[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해_06.:인덱스(Index)의 개념과 구조.

다음 포스트

[ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

DB : SQL(RDBMS,NoSQL,VectorDB) 이론 공부.

[ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

▽ [ DB & SQL(RDBMS, NoSQL) ] DB 모델링 개발의 순서.

1. 요구사항 분석.

🔍 Why: 왜 중요한가?

✅ 개념 정의.

🎯 What: 무엇을 분석하는가?

⚙️ How: 분석 방법

💡 실무 적용

⚙️ 의사결정 기준

💡 실무 Tip

요구사항의 종류

요구사항 - 기능적 요구사항.

요구사항 - 비기능적 요구사항.

2. 개체(Entity)와 속성(Attribute) 도출 (대부분 명사)

✅ 개념 정의.

🔍 Why

🎯 What

⚙️ How

💡 실무 적용

⚙️ 의사결정 기준

3. 개체 간의 관계를 추출(대부분 동사)

✅ 개념 정의.

💡 실무 적용.

⚙️ 의사결정 기준

4. 만들어진 개체-속성, 개체-관계를 바탕으로 개념적 설계(ERD)작성하기

✅ 개념 정의.

💡 실무 적용.

⚙️ 의사결정 기준

5. 논리적 설계 (DBMS 독립적)

✅ 개념 정의.

💡 실무 적용.

⚙️ 의사결정 기준

6. 물리적 설계 (DBMS 종속)

✅ 개념 정의.

⚙️ 의사결정 기준.

7. 정규화

✅ 개념 정의.

⚙️ 의사결정 기준.

⚙️ 반정규화

8. 물리적 구현

[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해_06.:인덱스(Index)의 개념과 구조.

[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해 07 : 데이터베이스 구조와 용어 정리. (RDBMS vs NoSQL vs Vector DB)

0개의 댓글