🌈 [Section2] 13. 데이터베이스 설계

📕 오늘 배운 내용!

• 데이터베이스 설계
• 스키마 디자인 실습

---

✏️ 관련 키워드

✔ 스키마(Schema)

➜ 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명
( 데이터베이스의 각 테이블의 구조와 테이블 간의 관계를 표현한 것이라고 생각하면 됨 )

Ex. 수강신청 시스템 만들 때,
일단 전체적인 화면 구성(어떤 데이터가 어떻게 표현되느냐)을 생각하여 Teachers, Students, Classes 등의 테이블을 만들어 데이터를 정의하는 방법이 스키마

✔ 엔티티(Entity)

• 고유한 정보의 단위

• 데이터베이스에서 각 테이블을 엔티티라고 할 수 있음

✔ 필드(fields)

• 해당 테이블 내의 요소(열)들

• 엔티티의 특성을 설명

• 한 테이블(엔티티) 안에는 ID 필드가 포함됨
  ➜ 각 필드의 고유한 ID들 = 해당 테이블의 기본 키(Primary key) 역할

• 한 테이블(엔티티) 안에 다른 테이블의 Primary key(ID 필드)를 가져와 참조할 때,
  그 값을 특정 레코드를 고유하게 식별하는 외래 키 (foreign key)라고 함

  Ex. Orders 테이블과 Customers 테이블이 있을 때,
  Orders 테이블에 Customers 테이블의 primary key(customersID)가 참조되어있다고 하면,

  • Orders.customersID ➜ foreign key
  • Customers.customersID ➜ primary key

✔ 레코드(record)

• 테이블 내에 저장된 항목(행)

---

✏️ 테이블과 테이블 사이의 관계

1:1 관계 (one-to-one) (일대 일 관계)

• 한 테이블의 하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우
  ( 실무에서는 대부분 대량의 정보를 다루기 때문에 연결 관계가 많아, 1:1 관계는 보통 자주 사용 X )

Ex. 위의 예시와 같이 Users 테이블과 Phonebook 테이블이 있다고 가정하면,
⠀
Users 테이블은 ID, name, phone_id 라는 열을 가지고 있고,
( 여기서 phone_id는 Phonebook 테이블의 ID와 연결된 외래키(foreign key) )
Phonebook 테이블은 ID와 phone_number를 가지고 있다.
⠀
이 예시에서, 한 phone_number은 단 한명의 user만 가질 수 있고,
반대의 경우도 가능하다면,
➜ 이 두 테이블의 관계는 1:1 관계라고 할 수 있음
⠀
( User 테이블에 phone_id를 대신해 phone_number를 직접 저장하는 게 나을 수 있음 )

✔ 1:N 관계 (one-to-many) (일대 다 관계)

• 하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우

Ex1. 위의 예시와 같이 Users 테이블과 Phonebook 테이블이 있다고 가정하면,
⠀
Users 테이블은 ID, name 이라는 열을 가지고 있고,
Phonebook 테이블은 phone_id, phone_number, user_id를 가지고 있다.
( 여기서 user_id는 User 테이블의 user_id를 참조한 외래키(foreign key) )
⠀
이 예시에서, 한명의 user는 여러 phone_number를 가질 수 있지만,
여러명의 user가 하나의 phone_number를 가질 수는 없다.
➜ 이 두 테이블의 관계는 1:N 관계라고 할 수 있음

---

Ex2. Teachers 테이블과 Classes 테이블이 있을 때,
여러 선생님이 한 과목을 가르친다 보다는 <한 선생님이 여러 과목을 가르친다>라고 말할 수 있음
(Teachers가 1, Classes가 다)
⠀
이 경우, Teachers 테이블의 각 필드(선생님 목록)에 Classes 테이블의 각 필드의 primary key(과목들 가리키는 ID)를 참조한다고 할 때 (1에 N을 참조한다고 할 때),
⠀
문제점 1) 테이블을 생성하면 해당 열의 크기는 정해져있기 때문에 과목 수가 많아진다면 수업 ID를 담을 공간이 부족할 수 있음
⠀
문제점 2) 해당 과목을 담당하는 선생님을 알아보기 위한 복잡도가 높아진다는 문제점이 있음
⠀
➜ 1:N 관계일 때 1에 N을 참조하지 않고 N에 1을 참조
Classes 테이블 내 각 필드에 Teachers의 foreign key(선생님 ID)를 참조한다면 효율적으로 사용 가능

✔ N:M 관계 (many-to-many) (다대 다 관계)

• 여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우
  ➜ Join 테이블 사용

Ex1. 여행을 예시로 들어, 위의 예시와 같이 Customer 테이블과 Package 테이블이 있을 때,
⠀
Customer 테이블은 ID, name 이라는 열을 가지고 있고,
여행 Package 테이블은 ID, name, package_id를 가지고 있다.
⠀⠀
이 예시에서, 한명의 Customer는 여러 Package 상품을 구매할 수 있고,
반대로, 하나의 Package 상품을 여러 Customer이 구매할 수 있다
➜ 이 두 테이블의 관계는 N:M 관계라고 할 수 있음
⠀
여기서 두 테이블의 관계를 나타내려면 각 테이블에다 각 테이블의 primary key들을 참조해야하는데,

➜ 이 때, 위와 같이 Join 테이블(두 테이블이 참조된 새 테이블)을 만들어서 참조할 수 있음
⠀
Join 테이블인 customer_package 테이블은 customer_id와 package_id를 묶어주는 역할이고,
이 테이블을 통해 어떤 고객이 몇개의 여행상품을 구매했는지 / 어떤 여행상품이 몇명의 고객을 가지고 있는지 확인 가능
( Join 테이블만의 primary key도 물론 생성해야함 )
⠀
(이는 1:N관계를 두번 쓴거나 마찬가지)

✔ 자기참조 관계 (Self Referencing Relationship)

• 테이블 내에서 참조한 관계
  ( 1:N(일대다) 관계와 유사하지만 테이블 몇개에서 참조하는지가 다름 )

Ex. 위의 예시에서,
User 테이블의 recommend_id는 User 테이블의 user_id와 연결되어 있음
⠀
한 명의 유저(user_id)는 한 명의 추천인(recommend_id)를 가질 수 있고,
여러 명이 한 명의 유저를 추천인으로 등록할 수 있음
➜ 이 경우, 자기 참조 관계

---

💬 강의에서의 Q )

만약 외래키를 리스트 형식으로 관리하는 필드가 있다면, 어떤 문제가 발생할 수 있을까?
( 조인 테이블 사용하지 않을 때의 문제점 )

💬 나의 Answer )

문제점 1. 테이블을 생성하면 해당 열의 크기는 정해져있기 때문에 참조할 데이터가 많을 때 그를 담을 공간이 부족해 저장을 못할 수 있음

문제점 2. 데이터를 조회하는데 많은 비용이 발생하게 됨

문제점 3. 데이터를 수정할 때 두 곳에 수정이 잘 되었는지 확인이 불편 (실수 유발 가능)

---

😜 스키마 디자인 실습 - 인스타그램

인스타그램의 각 기능들을 테이블로 하여 스키마 디자인을 해보았다!

각 테이블 및 필드를 설명하자면,

• Users 테이블
  고유 primary key인 id / name / email / password 필드를 가짐

• Following 테이블
  고유 primary key인 id / following_count / follower_count / user_id 필드를 가짐

  • 한 user가 여러명을 following 가능 (이게 제일 헷갈림 ㅠ 반대도 가능한가..?)
    ➜ 1:N 관계 (user_id에 참조함) (일단 이렇게 생각해서 이런 식으로 구현함)
    (이는 차차 알아보고 다시 수정할 것!)

• Post 테이블
  고유 primary key인 id / user_id / img / comments_id / created_At 필드를 가짐

• HashTag 테이블
  고유 primary key인 id / hashTag 필드를 가짐

• Post_HashTag 테이블 ( 위 Post 테이블과 HashTag 테이블의 Join 테이블 )
  고유 primary key인 id / hashTag_id / post_id 필드를 가짐

  • 한 post 안에 여러개의 hashTag 가능 (아래와 같이 반대도 가능)
    ➜ N:M 관계 (hashTag_id에 참조함)
    ⠀
  • 한 hashTag 누르면 여러개의 post 볼 수 있음 (위와 같이 반대도 가능)
    ➜ N:M 관계 (post_id에 참조함)
    ⠀
    ( 위 Post 테이블과 HashTag 테이블의 N:M 관계를 Join 테이블로 따로 빼서 표현 )

• Comments 테이블
  고유 primary key인 id / comments / user_id / post_id필드를 가짐

  • 한 user가 여러개의 comments 올리기 가능 (반대는 불가능)
    ➜ 1:N 관계 (user_id에 참조함)
    ⠀
  • 한 post에 여러개의 comments 있음 (반대는 불가능)
    ➜ 1:N 관계 (post_id에 참조함)

• Likes 테이블
  고유 primary key인 id / user_id / post_id 필드를 가짐

  • 한 user가 여러개의 likes 가능 (반대는 불가능)
    ➜ 1:N 관계 (user_id에 참조함)
    ⠀
  • 한 post에 여러개의 likes 가능 (반대는 불가능)
    ➜ 1:N 관계 (post_id에 참조함)

일단 이런 식으로 디자인을 해보긴 했는데 맞게 한 건지는 사실 모르겠다 ~,,

아래는 https://dbdiagram.io/home 에서 위 스키마 디자인 할 때 적었던 문장들이다! ⬇️
( 정확한 쿼리문은 아니고 다이어그램 문법에 가깝다 )

TABLE Users {
  id int
  name varchar
  email varchar
  password password
}
ref {
   Users.id > Post.user_id
}

TABLE Following {
  id int
  following_id int
  user_id int
}
ref {
  Following.user_id > Users.id
}

TABLE Likes {
  id int
  user_id int
  post_id int
}
ref {
  Likes.user_id > Users.id
}
ref {
  Likes.post_id > Post.id
}

TABLE HashTag {
  id int
  hashTag varchar
}

TABLE Post {
  id int
  user_id int
  img varchar
  comments_id int
  created_At timestamp
}
TABLE Comments {
  id int
  comments varchar
  post_id int
  user_id int
}
ref {
  Comments.user_id > Users.id
}
ref {
  Comments.post_id > Post.comments_id
}

TABLE Post_HashTag {
  id int
  hashTag_id int
  post_id int
}
ref {
  Post_HashTag.hashTag_id > HashTag.id
}
ref {
  Post_HashTag.post_id > Post.id
}

---

🌈 느낀점

디자인 구상하는 게 너무 헷갈렸다!!
처음엔 감도 안잡혀서 '뭘 어떻게 해야하는 거지..??' 하다가
다른 분들이 하신 스키마 디자인을 보고 어떤 구조로 이루어져서 디자인하는 건지 이해부터 했다
주어진 4시간 중에 2시간 정도를 이해하는데 썼는데 사실 제대로 이해한 건지는 모르겠지만
맞겠지..~~..
그래도 끝내 구현을 하긴 했는데 테이블 간의 관계를 표현하는 부분이 제일 헷갈린다
뭐가 어디에 참조되야할 지 머리로만 생각하려니 막막해서 종이에 쓰면서 구현을 끝냈다