TIL : 66번째- 230310 [3-1-금]

※ Keep in mind

 본 내용은 웹개발과정의 강의 중 내용을 복습을 위해서 메모한 것에 불과한 것입니다. 이러한 연유로 강의내용을 오인한 나머지 오기재 및 불기재가 있을 수 있으니 '참고'만 해주시길 바랍니다. 저의 경우에도 본 내용을 단순히 읽은 것이 결코 저의 것이라고 생각하지 않습니다. 본 내용은 복습를 위한 초기 내지 중간 과정에 불과한 것이고, 이후에 내용을 보충 후 인출 및 설명하기 과정이 있어야 비로소 복습의 단추가 어느정도 마무리 되어간다고 볼 수 있습니다.

 따라서 당초에 본 내용은 비공개였습니다. 그럼에도 불구하고 본 내용을 공개한 점은 함께 공부하는 동료들과 나눔을 바탕으로 배움과 성장의 공진화라는 소기의 목적을 달성에 어느정도 도움이 될수 있기 때문이라고 생각합니다.

 

I. 프로젝트 관련

1. 정리

entity(주체 대상자)/ relation(연결고리 : 행위 -> '저장'->업무)

여기서 절대로 논리설계단계인 테이블을 생각하는단계가 아니야

역할자 -> 대상

테이블을 만들어야하는가? : X (현재 개념설계단계 불과)
매핑테이블 : (두 테이블의 PK를 FK로 참조하는 테이블의 값을 저장할 때 사용됨 / 용도는 두테이블간의 참조를 용이하게 가능하다)

복합키 : 복합키(슈퍼키)란 두 테이블의 PK를 제3의 테이블에 PK로 동시에 이용할 를 의미한다.

 

2. 의문점

(1) 테이블은 나눌수록 좋은지? 적당한 칼럼(속성)의 수는?

(2) 릴레이션에 붙어있는 속성은 어떤의미?

 

 

3. 피드백

근로자가 근무정책에서 근무하다 문장?
주체는 맞는데, 근로자보다 사원

-- ( https://velog.io/@mong9_s/DBRDBMS-5.-ER%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8ERD )

 

<1조>

1안
문제점: 모양 안 맞음

사원이 회사에 근무하다 (근무 맞음?)
근무는 근무하는 날부터 근무
-> 출근 / 퇴근 각자 릴레이션임

테이블 생각은 논리설계 때 하는거야! 개념자체가 1안에서는 안보여
내가 하는 행위(출퇴근휴게)는 각자 하나의 릴레이션으로 해야해

근무 하나로 퉁치는 방식으로 하면 안돼


2안
모양은 맞음 그러나 나머지는 상술한바 마찬가지
X : 

<2조 : 공동구매>   

왜 N : N 이 아닌가? (당근마켓처럼)

회원 상품 관계 관련

'여러명의 회원'이 '하나상품' '채팅'

'하나의 상품'은 '여러명 회원' '채팅'오픈 

 

<3조>
수정이 작성
행위를 나눠서 할 때 작성, 수정 시 '날짜' 남기기
설정에 수정 릴레이션이 있다는건 저장을 의미해 그러려면 마찬가지로 수정날짜가 있어야해

<4조>
포트폴리오 등록 때 릴레이션에 회원아이디는 없애야해, 어차피 회원개체의 아이디 속성을 참조해서 가능해!
속성도 없는 애가 등록될 일도없어

우리는 테이블을 생각하는게 아냐!
등록되는거만 관심을 가져야해 / 삭제,취소는 관심이 없어

회원이 댓글을 등록하다 : 3,4형식 중 무엇?
3형식 : 
4형식 : 회원이 포트폴리오에 댓글을 등록한다 


삭제한 회원 정보 남기면 안됨 (개인정보 보호법)

 

II. DB 설계

1. 논리설계

(1) 들어가며

1)

<개념설계>한것을 사상시키면 논리설계야

 

<논리설계>란 어떤 DBMS에도 통용되는거야

테이블과 컬럼을 정하는거 까지야

 

<물리설계>란 자료형, 뷰 를 정의해

그런데 논리설계로 제너레이터 하면 자동으로 다 만들어줘

우리는 MySQL쓰잖아 이렇게 할 필요없어

 

(2) 논리설계

참고 

1) 1:N 관계

1:N 에서 메뉴 테이블에 들어가!

논리설계 시에 등록일자가 메뉴의 컬럼으로 들어가는거야

 

 

2) 상속관계

 

상속관계에서 두개가 하나의 테이블에 있어야할지?

역할이 완전히 나누어졌다면, 상속관계 표현안해! (즉 관리자는 회원페이지 못 들어가)

 

그러니까 회원에다가 관리자가 추가되면 속성으로 해 (타입이 확장되는거야!)

 

 

 

3)

1:N관계에서 등록일자를 넣은것과 마찬가지로 N부분에 회원의 PK를 메뉴의 FK로 넣어준다.

 

4)

한편 공개유무의 경우도 마찬가지이다 [???]

 

 

5)

우선 N:N은 두 테이블 사이에 별도의 테이블을 만드는데 이 별도의 테이블은 기존 두 테이블 사이에서 1:N관계를 가진다

 

추천이 N:N 맞아? 

관리자가 메뉴 여러개 가능 => O

메뉴가 여러 관리자에게 '각자' 추천될수있어? => O

 

결국 N : N 이면 별도의 테이블

엄마한테도 아빠한테도 갈 수없어

 

N:N일때 만들어진 테이블은 원래가지고있는 엔티티가 아니라 관계가 다대다라서 풀어내기 위해서 만든거야

기존에 가진 것은 키가된 엔티티라 하고 / 이거는 액션엔티티가 된거야

 

 

6)

 

이 경우 양쪽에 외래키로 두개로 회원아이디 메뉴아이디를 해줘

 

두개를 보고 차이를 살펴보자

<왼쪽> 처럼 별도의 키를 가질수있어

두개의 참조키를 엮으면 식별이 가능할수도 있어, 두개의 키가 하나의 식별자를 가진다해서 슈퍼키(복합키)라고 해

 

별도의 아이디를 두냐(좌) 로 차이가있다 / 혹은 복합키 형태로 참조하는 참조키를 묶어서 식별자를 쓰냐(우) 

 

<장단점은 뭘까?>

좌측 장점 : 아이디가 깔끔해

좌측 단점 : 부모가 가지고 있는 레코드 수보다 더 클수도 ( 예컨데 회원이 있는데 게시글이 있음, 그 아래 댓글 등 보면은 게시글 수가 10개이면 댓글은 10개보다 더 많을수가 있어! 그 숫자가 어마어마해져서 아이디 값이 굉장히 커져)

자식이 자식을 낳아서 테이블이 되면 키가 많이 커져!

그렇다고 long형으로 길게 가져가면 foreign 키로 식별자 가질수있다고 하면 키가 안늘어나

 

아이디가 계속 누적형

우측 : 조합형

장점 : 키가 안늘어나서 부모꺼 쓰면돼서 키가 안늘어나는 장점이있어

단점 : 비교할 때 항상 두개씩 비교해야해!

 

오른쪽이 가능하면 오른쪽 써야하는데 현실적으로 좌측을 쓰긴해

그런데 가능해야! 해 식별자로 쓸수있어야하는데 이를 식별관계라고 해

 

- 3번째 옵션 ??

두개의 컬럼합쳐서 하나의 컬럼을 둘 수있어

 

7)

우선 회원과 메뉴 사이는 1:N이기 때문에 다음과 같은 선의끝을 표현한다.

 

그렇다면 선의 끝이 아닌 실선 점선은 어떤 차이일까?

점선은 참조관계(비식별자관계) / 실선은 식별관계야

 

여기서 식별관계(실선)란 부모의 키가 PK로 포함된경우이고 / 비식별관계(점선)는 부모의 키가 일반속성으로 포함된 경우이다.

실선은 식별관계로서 있어

여행상품이 있어 회원이 여행상품 예약하는데 또 할수있으면 식별관계가 아냐

본 상황에서 회원이 추천을 한번더 할 수 있는가? : 수정이지 또 추천은 X

 

8)

많이들 쓰는 기본키 방식을 쓰자

---

1. 보충

(1) 식별관계?

 

 

 

2. 회고 

1) 확실히 설계가 여러가지로 적용하기에 어려움이 많은것 같다.

학교다닐때 할때가 많이 생각이난다.