DB 설계의 규칙 첫번째, 한 칸 한 정보

💡 한 칸에 한 정보?

데이터베이스 테이블을 설계할 때 ‘한 칸에는 한 가지 정보만 들어가야 한다.’라는 규칙을 지켜야 한다. 이 규칙이 뭔지 알아보기 위해 이 규칙을 안 지킨 사례 먼저 살펴보자.

 

[사례 1]

[사례 2]

stores (가게)

위 사례를 살펴보면 한 칸에 2가지 이상의 정보가 들어가있는 걸 확인할 수 있다.

 

📌  왜 한 칸에는 두 가지 이상의 정보가 들어갈 수 없을까?

위 예시처럼 2개 이상의 정보가 들어가면 data를 조회할 때, 콤마(,)를 제거하고 각각 배열에 넣는 로직이 필요하다.

그래야 구별 가능하기 때문이다. 만약 두 개의 데이터를 하나의 데이터로 간주하면 컴퓨터는 "JS아메리카노, JS카페라떼"가 하나의 

메뉴명으로 알 수도 있다.

또한 이렇게 한 칸에 여러개의 정보를 넣을 수 있으면 중복의 가능성이 존재한다. 넣었던 데이터를 또 넣는 실수를 저지를 수 있기 때문이다.

 

📌  Signal(한 칸에 두가지 이상의 정보) == table을 분리하라는 신호

[사례  - 테이블 분리]

users (사용자)

emails (이메일)

테이블을 분리하는 것까진 좋은데 위와 같이 테이블을 분리하면, 특정 사용자의 이메일 주소를 알 수 있는 방법이 없다. 특정 사용자의 이메일 주소가 어떤 건지 알 수 있게 테이블을 보완해보자.

 

 

[사례  - 잘못된 분리]

위와 같이 데이터를 저장하니 특정 사용자의 이메일 주소를 알 수는 있게 됐다. 하지만 한 칸에 2가지 이상의 정보가 다시 들어가게 됐다. 이럴 때는 FK를 다른 테이블로 옮겨보자. 즉, FK의 위치를 users 테이블에서 emails 테이블로 옮겨보자.

 

 

[사례  - 최종]

위와 같이 데이터를 저장하니 특정 사용자의 이메일 주소도 알 수 있고, 한 칸에 한 가지의 정보만 들어가게 만들었다. 위와 같이 테이블을 분리해야 한다.

다시 한 번 정리해보자.

한 칸에 두 가지 이상의 정보가 들어가있을 땐, 테이블을 분리해서 FK를 활용해 한 칸에 한 가지의 정보만 들어가게 만들어야 한다.

 

이래서 Foreign Key를 1:N의 관계에서 N쪽에 설정하여 설계하는 것이다. 한 칸 한 정보 규칙을 지키기 위해서...

 

이 규칙이 제 1 정규화이다.

 

🚀 한 가지 정보라는 것이 관점에 따라 달라질 수 있다(심화)

누군가는 박재성이라는 전체 이름이 하나의 정보라고 생각할 수 있지만, 누군가는 박이 하나의 정보고, 재성이 하나의 정보라고 판단할 수도 있다. 둘 다 올바른 관점이다. 말 그대로 ‘한 가지 정보’라는 건 절대적이지 않다. 자신의 서비스에 맞게 판단해야 한다.

그럼 어떻게 판단해야 할까? → 서비스에서 데이터의 사용 방식에 따라 결정해야 한다!

예를 들어, 서비스에서 성과 이름을 따로따로 조회해야 하는 경우가 많다면 2번째 테이블의 형태로 구성하는 게 좋다. 반대로 서비스에서 성과 이름을 따로따로 조회할 일이 없고 통째로 쓰는 경우만 있다면 1번째 테이블의 형태로 구성하는 게 좋다.

---

이와 비슷한 예시를 하나 더 알아보자.

누군가는 전화번호가 하나의 정보라고 생각할 수도 있지만, 누군가한테는 전화번호는 3가지의 정보라고 생각할 수 있다. 둘 다 맞는 말이다. 어떻게 테이블을 설계해야 하는 지는 서비스에 맞게 판단하면 된다. 만약 전화번호의 3가지 정보를 분리해서 따로따로 사용해야 하는 경우가 있다면 두 번째처럼 설계를 해야 한다. 그렇지 않다면 첫 번째처럼 설계를 하면 된다.

 

🔬  ‘한 가지 정보’의 기준은 절대적이지 않다. 따라서 서비스에 맞게 판단해야 한다.