미션으로 제작한 ERD....인데 많이 더럽다.

Mission 1

미션 자료로 제공된 피그마를 보고 ERD를 설계한 후 제 1,2,3 정규화하기

• 미션을 위해 만들었던 기존의 ERD를 정규화 하는 과정을 진행해보자.

정규화

-제 1정규화

• 각 테이블의 컬럼이 위의 규칙을 만족하게 변경해야한다.
  다행히 ERD 설계시 data의 중복이 없도록 테이블을 구성하여 1정규화는 완료되었다.

-제 2정규화

• 부분적 종속이란?
  기본 키가 아닌 다른 컬럼에 특정 컬럼이 종속되는, 즉 기본 키가 아닌 특정 칼럼만으로 다른 칼럼이 구분 가능할 때, 해당 컬럼은 특정 칼럼에 부분적 종속되는 것.

• ERD 설계중 다음과 같이 store 테이블을 작성했는데,
  

• '식당 아이디'의 기본 키에 종속되는 locate와 name 컬럼에서 name 컬럼이 locate 컬럼에 부분적 종속이 이루어질 수 있다고 판단, 다음과 같이 테이블을 분리했다.

-제 3정규화

• 제 3정규화의 경우 아래의 미션 테이블에서 정규화의 필요성을 느꼈다.

• 복합 키(미션아이디 + 식당아이디)를 통해 미션 이름에 접근하고, 미션 이름을 통해 미션 포인트에 접근할 수 있는데, 이 경우 한 테이블에 존재하기 때문에 이행 종속성이 존재한다. 따라서 다음과 같이 테이블을 분리해주었다.

참고자료 및 출처

Mission 2

피그마의 홈 부분에서 한 사람이 “미션 도전!” 버튼을 빠르게 여러 번 눌렀을 때 여러 가지 이유(비동기 로직 등)로 요청이 지연되어 완전히 처리하기 전 두 번 요청이 들어갈 수 있습니다. 이를 해결할 수 있는 방법에 대해 작성해보기

1.해당 버튼을 제출을 한번 누르고 나면 disable 시키기

• 적절한 상황에서 사용하면 가장 간편하고 좋은 방법이지만 여러 케이스에서 단순히 버튼 클릭만 막는다고 해결되진 않는다는 단점이 있다.

2. 난타로 인해 발생하는 로그인 화면 중복 실행의 경우 비동기 중복 요청 방지를 위해 List를 사용하기.

• Key 외에는 다른 값이 필요 없으므로 List가 사용에 적합. Map도 사용 가능
• 비동기 요청 전에 자신의 Key(Method와 URL 조합)를 List에 추가하고 요청이 완료(성공이든 실패이든)되면 List에서 해당 Key를 삭제하는 방식으로 운용.

  즉, List에 Key값이 있는 경우, 해당 요청이 처리 중이므로 요청을 거부하는 방식!

참고자료 및 출처1
참고자료 및 출처2