![[DB] 데이터베이스 설계 전체 과정](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FCgKtl%2FbtsLSrKLKiM%2Fhkb7JgTHkC9sLSzEf7Uv6K%2Fimg.png)
[DB] 데이터베이스 설계 전체 과정DB2025. 1. 19. 00:56
Table of Contents
728x90
데이터베이스 설계 전체 과정
저장해야 할 데이터 파악
- 요구사항 또는 디자인(UI)를 보고 저장해야 할 데이터를 파악
그룹핑해서 분류하기
- 관련성 있는 데이터를 묶어 그룹핑
- 그룹핑할 수 있는 상위 개념을 찾아 데이터 구조화
6가지 규칙 적용시키면서 테이블 분류하기
- 아래 규칙에 따라 테이블을 설계
규칙 1. 한 칸에는 한 가지 정보만 들어가도록 만든다. (제1정규형)
- 한 칸에는 반드시 한 가지 정보만 포함되어야 함
- 한 칸에 두 가지 정보가 들어가 있는 경우, 테이블을 분리하고 FK(Foreign Key)를 활용
- 한 가지 정보라는 기준은 서비스에서 데이터를 사용하는 방식에 따라 달라질 수 있음
예시: 잘못된 설계
주소가 한 칸에 통합된 경우
사용자 ID | 이름 | 주소 |
---|---|---|
1 | 홍길동 | 서울시 강남구 |
2 | 김영희 | 부산시 해운대구 |
수정 후: 올바른 설계
주소를 시와 구로 분리
사용자 ID | 이름 | 시 | 구 |
---|---|---|---|
1 | 홍길동 | 서울시 | 강남구 |
2 | 김영희 | 부산시 | 해운대구 |
하지만 서비스에서 데이터 사용하는 방식에 따라 달라질 수 있다.
반드시 위의 예시가 잘못된 설계와 올바른 설계가 아닐 수 있다.
규칙 2. 어떤 테이블에 FK를 넣어도 "규칙 1"을 지킬 수 없을 때는 중간 테이블을 만든다.
- FK를 추가해도 데이터 중복이 발생하거나 규칙 1을 충족하지 못할 경우, 중간 테이블을 생성하여 관계를 재구조화
예시: N:M 관계를 처리하기 위한 중간 테이블
- 사용자와 프로젝트 간의 관계는 N:M 관계
- 중간 테이블
user_projects
를 추가하여 1:N 관계로 변환
사용자 테이블
사용자 ID | 이름 |
---|---|
1 | 홍길동 |
2 | 김영희 |
프로젝트 테이블
프로젝트 ID | 프로젝트 이름 |
---|---|
1 | 데이터 분석 |
2 | 웹 개발 |
중간 테이블: user_projects
사용자 ID | 프로젝트 ID |
---|---|
1 | 1 |
1 | 2 |
2 | 2 |
규칙 3. 관계(1:1, 1:N, N:M)를 파악한다.
- 테이블 간의 관계를 분석하여 설계
예시 1: 1:1 관계
- 사용자와 프로필 정보는 1:1 관계
- FK를 추가하거나 두 테이블을 통합할 수 있음
사용자 테이블
사용자 ID | 이름 |
---|---|
1 | 홍길동 |
2 | 김영희 |
프로필 테이블
사용자 ID | 프로필 사진 URL |
---|---|
1 | url1 |
2 | url2 |
예시 2: 1:N 관계
- 고객과 주문은 1:N 관계
- 주문 테이블에 고객 ID를 FK로 추가
고객 테이블
고객 ID | 이름 |
---|---|
1 | 홍길동 |
2 | 김영희 |
주문 테이블
주문 ID | 고객 ID | 주문 날짜 |
---|---|---|
1 | 1 | 2025-01-01 |
2 | 1 | 2025-01-05 |
3 | 2 | 2025-01-10 |
규칙 4. 데이터 중복이 발생하는 컬럼이 있는지 확인한다.
- 데이터 중복 여부를 시뮬레이션하고 중복 문제를 방지
- 특정 컬럼에서 데이터 중복이 발생하면 테이블을 분리하여 설계
예시: 고객 정보 중복 제거
Before: 데이터 중복 발생
주문 ID | 고객 이름 | 고객 이메일 | 주문 날짜 |
---|---|---|---|
1 | 홍길동 | hong@example.com | 2025-01-01 |
2 | 홍길동 | hong@example.com | 2025-01-05 |
After: 중복 제거 후 설계
고객 테이블
고객 ID | 고객 이름 | 고객 이메일 |
---|---|---|
1 | 홍길동 | hong@example.com |
주문 테이블
주문 ID | 고객 ID | 주문 날짜 |
---|---|---|
1 | 1 | 2025-01-01 |
2 | 1 | 2025-01-05 |
규칙 5. 가짜 중복과 진짜 중복을 구별한다.
- 진짜 중복: A 데이터 수정 시, B 데이터도 수정되어야 하는 경우 (테이블 분리 필요)
- 가짜 중복: A 데이터와 B 데이터가 독립적일 경우 (테이블 분리 불필요)
예시: 진짜 중복과 가짜 중복
- 진짜 중복: 고객 정보가 주문 테이블에 반복 저장
- 가짜 중복: 주문 날짜가 여러 주문에서 동일한 경우
규칙 6. 숨어있는 중복을 찾는다.
- 시뮬레이션을 통해 처음에는 보이지 않던 중복을 발견하고 수정
예시: 중복된 열 분리
Before: 중복된 데이터
주문 ID | 제품 이름 | 제품 가격 |
---|---|---|
1 | 스마트폰 | 1000000 |
2 | 스마트폰 | 1000000 |
After: 중복 제거
제품 테이블
제품 ID | 제품 이름 | 제품 가격 |
---|---|---|
1 | 스마트폰 | 1000000 |
주문 테이블
주문 ID | 제품 ID |
---|---|
1 | 1 |
2 | 1 |
결론
데이터베이스 설계는 데이터 중복을 방지하고, 효율적인 데이터 관리를 위해 규칙을 적용하며 단계적으로 진행해야 함.
관계 파악과 중복 제거는 데이터 무결성을 유지하는 핵심 요소임
'DB' 카테고리의 다른 글
[DB] 데이터베이스 설계 핵심 1가지 (0) | 2025.01.19 |
---|---|
[DB] 데이터베이스 네이밍 규칙 (0) | 2025.01.18 |
[DB] 관계형 데이터베이스(RDBMS) 구성 (0) | 2025.01.18 |
[DB] 데이터베이스 모델링이란? (0) | 2025.01.18 |
[DB] 지속성(Durability) (0) | 2024.12.01 |
@mane Lab :: 마네의 연구소
배움에 즐거움을 느끼는 마네의 연구소입니다. 이미지 출처 : https://www.instagram.com/hoseobiiiiiii._.0410/
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!