Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

Today I Learned

설계(Design) 본문

DB

설계(Design)

꾸주니12 2022. 5. 7. 23:19
  • 테이블에 들어갈 값과 제약조건 연간관계를 정의 하는 것을 모델링 이라고 함
  • 모델링 한 설계 도면을 우리는 ERD 라고 부른다.
  • 설계한 내용에 대한 테스트 및 검증이 필요하다.

 

  • 설계할 때 무슨테이블이 들어가겠네 테이블에 어떤데이터가 들어가겠네 연결관계 생각하기 
  • 설계는 정답이 없고 제대로 돌아가기만 하면 됨 

 

 

[sns service]

기능 

1. 회원가입 2.profile등록 3.회원 profile보기 4.글쓰기 5.reply쓰기 6.글보기 7.유저가 작성한 reply 보기 8.친구목록 보기 9.좋아요 누른 사람들 보기

- 회원가입은 id,비밀번호,email,이름을 입력하여 진행

- 선택적으로 프로필을 등록할 수 있음

- 프로필 등록에는 다니는 학교와 회사를 입력

- 글과 댓글을 작성할 수 있음 

- 이 글에는 등록날짜, 조회 수, 좋아요 숫자를 보여준다.

- 좋아요는 로그인한 회원이 게시글 별로 한번만 가능하다.

- 해당 글에는 댓글을 달 수 있다.

  • 내가 못한 부분 
  • 좋아요 부분이 제일 어려웠음 글테이블이랑 회원테이블이랑  연결해서 볼수있게 
  • 프로필 테이블이랑 이랑 회원 테이블을 식별관계로 했음 / (식별관계는 부모의 기본키를 자식이 기본키로 사용하면 식별관계) 여기선 멀티 프로필을 만들수있다고 생각하고 1대 다 관계로 (그리고 1:1 관계는 쉽게 하지말자)
  • 댓글테이블에 댓글번호를 추가하여 기본키로 설정하는걸 못함 
  • 기본키를 설정할까 말까 고민될때는 콕찝어서 삭제 및 수정이 필요한 경우에 하기 

 

< 설계할 때>

0. 여러사람의 눈으로 봐야된다.

1. 어떤 테이블이 존재하는지 따져보기  - 만들면서 쪼개던지 합치던지 

2. 테이블 만들기 - 키를 줄까 말까 정하기 

3. 1:1 은 신중하게 쓰기 식별관계가 맞아도 비식별관계로 하기 

(프로필 바꿀 때 이전 히스토리가 남아있으려면 식별관계면 안된다. - 요구사항엔 없지만 추가 )

4. 프로필 작성일 - 날짜순으로 최신으로 가져올거야 

5. Pk 가 필요한가 ? 콕찝어야 할 필요가 있나? 할 때 pk 넣기 - 글 ) 글 삭제할 때  글 선택할때 

6. 글에 작성자 있어야함 이상한글이 올라오거나 누가썼는지 확인 필요 

7. 댓글도 pk 필요 (글 과 같은 원리 )

8. 친구번호도 pk 넣은건 딱 하나만 찝어서 삭제할 수 있기 때문

9. 좋아요는 리스트임 /  있어 없어 이기때문에 pk 필요 없음 

 

 

 

 

[shopping]

- 회원은 일반회원과 판매자 회원

- 일반회원은 아이디, 비밀번호,배송지 주소,연락처 을 입력

- 장바구니 테이블은 판매 품목에서 장바구니에 담은 아이템을 넣음

- 장바구니에서 구매한 목록은 구매 테이블에 추가

- 구매 테이블에는 사용자아이디, 물품아이디, 물품이름, 가격, 구매 날짜 등이 저장

- 판매 품목에는  품목아이디,품목이름, 가격, 판매자 아이디, 소속 카테고리 존재

- 판매 품목에는 대분류,중분류,소분류를 가지고 있음

- 카테고리는 대분류,중분류,소분류를 고를 때 마다 해당 분류의 물품이 바로 나타남

- 판매 품목은 판매자 회원이 올릴 수 있음

- 판매자 회원은 아이디, 비밀번호, 계좌번호 필드가 있음

- 판매자는 본인이 판매한 물품들과 매출을 계산할 수 있어야함

- 판매품목에는 구매후기가 달린다 

팀이 한거
강사님이 한거

 

  • 나는 카테고리가 대, 중, 소 3개로 구분된다고 이해했는데, 대분류 - 중분류 - 소분류로 줄여 드는 것 - 잘 읽고 잘 이해하기 
  • 구매후기를 작성한 사람이 구매한건지 확인하는 방법? - 구매후기 테이블엔 일반회원아이디와 품목아이디 가 있으니까 구매 테이블에서 대조해서 해결 가능
  • 장바구니 테이블은 없어도 된대 구매테이블에 장바구니 여부로 쓰고 y면 장바구니에 있는거고 구매날짜가 안찍히면 구매가 아직안된거? n이면 장바구니에 없는거고
  • 일반회원과 판매자회원을 합칠까? 합치면 일반회원에는 계좌번호가 null 이되고 판매자 회원테이블에선 배송지주소가 null이 됨 - 제1정규화 위배 - 합치지 마
  • 매출통계 내 판매자아이디에 관련된 ‘판매품목’ ‘언제팔고 ‘얼마를 팔고’
  • 구매테이블에 - 물품이름, 가격 안넣어도된다 품목아이디 있으면 판매품목테이블에 다 적혀있으니까
  • 굳이 매출테이블 안만들어도된다.품목아이디랑 가격 가지고 계산하면되서?
  • 구매후기 - 후기번호 기본키 설정 - 특정후기 수정하거나 특정후기 삭제하려면 

 

 

 

 

[library]

 

 

<피드백>

- 예약을 했는데 무제한 예약인건가? 예약내역이 바뀌면 예약된거다 라고 대답  

- 회원테이블에 예약내역 이라는 컬럼이 있었는데 뺌 예약테이블이 곧 예약내역이잖아 둘이 연결 됐으니까(회원번호를 외래키로씀) 

- 대출이되면 예약이 종료가 되고, 노쇼 예약을 하고 대출을안하면 예약이 종료되도록 설정해야함  — 깊이있게 생각하기 고민한 흔적이 있어야 함 생각도없으면안됨! - 예약테이블에 (예약날짜,예약종료) 추가함 

- 회원의 대출이력은 대출테이블에서 회원번호 연결되어있으니까 확인가능 (대출이력테이블 따로 만들었었는데 없앰)

- 대출테이블에 반납테이블 합쳐도 되지만 반납이 안되면 null 이 들어가니까 제 1정규화 위배 이게 상관없으면 합치기 

'DB' 카테고리의 다른 글

정규화(normalization)  (0) 2022.05.07
뷰(View)  (0) 2022.05.06
인덱스  (0) 2022.05.06
in & exists 그리고 any & all  (0) 2022.05.02
집합  (0) 2022.05.01