⭐️복잡한 개념을 몰라도 누구나 따라할 수 있는, 마법의 DB 설계 규칙 5가지⭐️

2025. 8. 20. 19:42개발/DB

반응형

* 이 글은 개발 공부를 위한 블로그글로 지식전달보다는 개발 공부 일지에 초점이 맞춰져 있으니 유의하시길 바랍니다.

[규칙 1] 한 칸에는 한 가지 정보만 들어가도록 만들어라

왜 2가지 이상의 정보가 들어가면 안되는 걸까?

- ,를 신경써서 작업해야 되기 때문이다.

- 한 개의 데이터에 여러가지 데이터가 들어가게 되면 중복이 발생할 수도 있다.

 

한 칸에 2개 이상의 정보가 들어가있을 때?

- 테이블을 분리하면 된다.

- 분리해서 한 칸에 한 가지 정보만 들어가야 한다.

- 이를 제1정규형이라고 한다. 

- 특정 테이블에 FK를 도입했을 때 규칙 1 이 안 지켜진다면, 다른 테이블로 FK를 옮겨보자.

- 정처기 필기에서는 제 1정규형을 만들기 위해서는 원자성을 제거하라고 했었다.

 

관점, 서비스에 따라서 한 가지 정보라는 것이 달라질 수 있다.- 이름을 생각했을 때, 보통 '홍길동'을 저장한다. 하지만, 성과 이름을 분리해야 하는 상황이 있을 수도 있다.- 그러면 성, 이름이라는 속성으로 나누어 각각 '홍', '길동'으로 저장해야한다.- 전화번호도 있다. 03211112222를 032, 1111, 2222로 저장하여 지역번호를 나누어야 하는 서비스에 적용할 수도 있을 것이다.그러므로 DB설계는 개발 상황, 요구조건 등이 바뀜에 따라 계속해서 개선, 수정을 해주어야 한다.

 

[규칙 2] 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 못 지킬 때는 중간 테이블을 하나 더 만들어라

- 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 못 지킬 때는 중간 테이블을 하나 더 만들어라.

- 중간 테이블의 이름을 지을 때, 각각의 테이블의 이름을 통해 ~를 한다. 라는 어울리는 동사를 생각하여 명명하자.

[규칙 3] 헷갈릴 땐 관계(1:1, 1:N, N:M)를 파악해봐라

1:1 관계 / 1:N 관계 / N:M 관계 ?

엔티티 관계 파악 방법

  1. 엔티티 간에 어울리는 동사 찾기
    • A(주어)가 B를 _____. (A가 주어)
    • B(주어)가 A에 의해 ______. (B가 주어)
    서비스의 관점에서 동사를 떠올려야 한다.
  2. 1번 과정에서 찾은 동사를 활용해 적절한 단어(하나의 or 여러 개의) 찾기
    • 하나의 A는 (하나의 or 여러 개의) B를 _______. (A의 관점)
    • 하나의 B는 (하나의 or 여러 개의) A에 의해 _______. (B의 관점)
     문장 처음에 시작하는 하나의라는 말을 반드시 붙여야 헷갈리지 않는다. 서비스를 어떻게 기획하냐에 따라 달라질 수 있다. 반드시 자신의 서비스에 대입해서 생각해야 한다.
  3. 관계 판단하기
    • A, B의 관점 전부 다 하나만 기진다면 → A : B = 1 : 1
    • A의 관점에서는 여러개의 B를 가지고, B의 관점에서는 하나의 A를 가진다면 → A : B = 1 : N
    • A의 관점에서는 하나의 B를 가지고, B의 관점에서는 여러개의 A를 가진다면 → A : B = N : 1
    • A, B의 관점 전부 다 여러개를 가진다면 → A : B = N : M 

예시 1 : 사용자 (users), 이메일 (emails)

  • 사용자가 이메일을 소유한다.
  • 이메일은 사용자에 의해 소유된다.
  • 한 명의 사용자는 여러 개의 이메일을 소유한다(소유할 수 있다).
  • 하나의 이메일은 한 명의 사용자에 의해 소유된다.

⇒ 사용자 : 이메일 = 1 : N 관계

  • (한 명의 사용자가 회원가입 할 때 여러 개의 이메일을 입력할 수 있는 서비스라고 가정하자.)

✅ 예시 2: 가게 (stores), 판매 상품 (products)

  • 가게가 판매 상품을 판다.
  • 판매 상품은 가게에 의해 팔린다.
  • 하나의 가게는 여러 개의 상품을 판다(팔 수 있다).
  • 하나의 상품은 하나의 가게에 의해 팔린다.

가게 : 상품 = 1 : N

 

✅ 예시 3: 학생 (students), 수강 과목 (courses)

  • 학생이 수강 과목을 듣는다.
  • 수강 과목은 학생에 의해 들어진다.
  • 한 명의 학생은 여러 개의 수강 과목을 듣는다(들을 수 있다).
  • 하나의 수강 과목은 여러 학생에 의해 들어진다.

학생 : 수강 과목 = N : M

 

✅ 예시 4: 영화 (movies), 배우 (actors)

  • 영화는 배우를 출연시킨다. (엄청 자연스럽지 않아도 된다.)
  • 배우는 영화에 의해 출연된다.
  • 하나의 영화는 여러 배우를 출연시킨다(출연시킬 수 있다).
  • 한 명의 배우는 여러 영화에 의해 출연된다(출연될 수 있다).

영화 : 배우 = N : M

 

✅ 예시 5: 사용자(users), 프로필(profiles)

  • 사용자는 프로필을 가진다.
  • 프로필은 사용자에 의해 소유된다.
  • 한 명의 사용자는 한 개의 프로필만 가진다(가질 수 있다).
  • 한 개의 프로필은 한 명의 사용자한테만 소유된다.

사용자 : 프로필 = 1 : 1 관계

 

✅ 1:N 관계의 특징

  • N 쪽의 테이블에 FK가 들어가야 한다.

✅ N:M 관계의 특징

  • 중간 테이블이 있어야 한다.
  • 중간 테이블에 두 테이블의 FK가 들어가야 한다.
  • N:M 관계에서 중간 테이블을 추가해 1:N 관계로 바꿔 표현하게 된다.

✅ 1:1 관계의 특징

(DB 설계할 때는 1:1 관계가 생각보다 잘 안 나옴)

  • 아무 테이블에 FK를 넣어도 된다.
  • 합쳐도 되는 지 고려해봐야 한다. (어지간하면 1:1 관계로 분리하지 않는 걸 추천한다.)
  • 분리하지 않는 것이 더 간단할 수도 있다.(데이터를 불러올 때, join을 해야되는 상황이 발생할 수 있음.)

[규칙 4] 데이터 중복이 발생하는 컬럼이 있는 지 확인해라

 데이터 중복이 발생하는 지 시뮬레이션을 돌려봐라.

- 데이터를 분리해서 중복을 제거한다.

✅ 이런 중복은 어떻게 해결할까?

[규칙 5] 가짜 중복과 진짜 중복을 구별해라

- 중복되는 여러 데이터행들중에 하나가 바뀌면 다른 것도 다 바뀌어야 되는가? 를 확인해본다.

- 가짜 중복이 발생한 컬럼은 테이블 분리를 하면 안 된다. 진짜 중복이 발생한 컬럼에 대해서만 테이블 분리를 해야 한다.

[규칙 6] 숨어있는 중복을 찾아라

 숨어있는 중복을 찾아라.

- 좋아요 테이블에서 한 행을 삭제하게 되면 게시글 테이블에 좋아요수가 제대로 집계되지 않는 이상현상이 발생한다.

- 이를 숨어있는 중복이라하고 중복과 같은 단점으로 보여진다.

- 좋아요 수 칼럼을 없애고, likes 테이블을 활용해서 좋아요 수를 카운팅하면 된다.

반응형