[실습] 요구사항을 보고 DB 설계해보기 - JSCODE 커뮤니티

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

 

이전에 배웠던 것을 적용해보자!

✅ 요구 사항

• 회원가입 기능
  • 회원가입을 할 때 이메일, 비밀번호, 이름, 나이의 정보를 받는다.
• 로그인 기능
  • 로그인할 때 이메일, 비밀번호를 활용해서 로그인한다.
• 게시글 작성 기능
  • 로그인한 사용자만 게시글을 작성할 수 있다.
  • 게시글에는 제목과 내용을 작성할 수 있고, 해시태그를 달 수 있고, 게시글의 카테고리(정보 게시글, 홍보 게시글 등)를 고를 수 있다.
• 게시글 조회 기능
  • 작성자, 게시글 제목, 게시글 내용, 게시글 작성 시간, 좋아요 수, 조회 수를 조회할 수 있어야 한다.
• 해시태그로 게시글 조회 기능
  • 특정 해시태그를 가진 모든 게시글을 조회할 수 있어야 한다.
• 좋아요 기능
  • 로그인한 사용자가 특정 게시글에 좋아요를 누를 수 있다.
  • 로그인한 사용자가 특정 게시글에 좋아요 취소를 할 수 있다
  • .
  • 특정 게시글에 어떤 사용자들이 좋아요를 눌렀는 지 조회할 수 있어야 한다.
• 팔로우 기능
  • 특정 사용자가 다른 사용자를 팔로우 할 수 있다.
  • 특정 사용자가 다른 사용자를 언팔로우 할 수 있다.
  • 각 사용자의 팔로우 수를 조회할 수 있어야 한다.
• 신고 기능
  • 로그인한 사용자가 특정 게시글을 신고할 수 있다.
  • 신고할 때 신고 사유를 작성해야 한다.

1. UI, 요구사항 명세서를 보고 저장할 데이터를 파악한다.

• 이메일, 비밀번호, 이름, 나이
• 게시글 제목, 게시글 내용, 게시글에 달린 해시태그, 게시글의 카테고리, 게시글 작성자, 게시글 작성 시간, 게시글 좋아요 수, 게시글 조회 수
• 어떤 게시글에 어떤 사용자가 좋아요를 눌렀는 지
• 어떤 사용자가 누구를 팔로우 했는 지
• 팔로우 수
• 어떤 사용자가 어떤 게시글을 신고 했는 지, 신고 사유

2. 데이터를 그룹화해서 분류한다.

• 이메일, 비밀번호, 이름, 나이 → 사용자
• 게시글 제목, 게시글 내용, 게시글에 달린 해시태그, 게시글의 카테고리, 게시글 작성자, 게시글 작성 시간, 게시글 좋아요 수, 게시글 조회 수 → 게시글
• 어떤 게시글에 어떤 사용자가 좋아요를 눌렀는 지 → 게시글? 사용자?
• 어떤 사용자가 누구를 팔로우 했는 지 → 사용자?
• 팔로우 수 → 사용자
• 어떤 사용자가 어떤 게시글을 신고 했는 지, 신고 사유 → 신고

3. 6가지 규칙에 따라 테이블을 분리시키면서 DB를 설계한다.

 

직접 실습

1. 데이터 파악하기

• 이메일, 비밀번호, 이름, 나이 -> users
• 게시글 제목, 게시글 내용, 해시태그, 카테고리, 작성자, 게시글 작성시간, 좋아요 수, 조회 수 -> posts
• 좋아요 누른 게시글, 좋아요 누른 사용자 -> likes
• 팔로우한 사람, 팔로우당한 사람 -> followers
• 신고한 사용자, 신고한 게시글, 신고 사유 -> reports

2. 엑셀로 6가지 규칙 적용하여 정규화하기

사용자(users)	id	이메일	비밀번호	이름	나이
게시글(posts)	id	제목	내용	카테고리이름catagories_id(FK)	작성자users_id(FK)	작성시간
해시태그(hashtags)	id	해시태그이름
해시태그_게시글(hashtags_posts)	id	hashtags_id(FK)	게시글posts_id(FK)
카테고리(categories)	id	카테고리이름
좋아요(likes)	id	좋아요누른 게시글posts_id(FK)	좋아요누른 사용자users_id(FK)
조회수(views)	id	조회한 게시글posts_id(FK)	조회한 사용자users_id(FK)
팔로우(follow)	id	팔로우한 사용자users_id(FK)	팔로우받은 사용자users_id(FK)
reports	id	신고한 사용자users_id(FK)	신고한 게시글posts_id(FK)	신고사유

 

3. ERD를 통해 자료화하기 ​

* erdcloud에서 Identifying Relationship(식별 관계)은 FK가 PK로 사용될 때, 종속이 되어있을 때 사용하고, 파란색 화살표이다.

부모 테이블이 삭제되면 자식 테이블의 데이터도 삭제되어야 하는가? => YES

* Non Identyfing Relationship(비식별 관계)은 FK이지만, 종속되어있지 않을 때 사용하고, 핑크색 화살표이다. 부모 릴레이션의 PK가 변경되도 FK값은 여전히 값이 유지됨을 뜻한다.

* In ER diagrams (ERDs), an identifying relationship signifies a dependency where a child entity's primary key includes the primary key of its parent entity. This means the child entity cannot exist without a corresponding entry in the parent entity. It's visually represented by a solid line connecting the entities. This is from Gemini.

=> 자식 개체의 PK가 부모 개체의 PK를 포함한다. 즉, 부모 개체가 삭제되면 자식 개체도 사라진다.

* 개념은 이해가 가는데, 비식별 관계에서 독립적으로 테이블이 존재할 수 있다는 것이 이해가 가지 않는다. 이 ERD를 보면 사용자ID FK로 많이 이용된다. 확실히 자식 릴레이션에서 PK로 사용되지 않기 때문에, 식별관계가 아님을 알 수 있지만, 그렇다고 해서 부모 릴레이션이 사라지면, 자식 릴레이션에서 개체는 유지되어도 사용자ID는 알 수 없지 않은가? 그러면 여기서 존재의 유무를 논의하는 것은 개체인건가?