Happiness can be found even in the dark Happiness can be found even in the dark

필자는 앞서, 개념적 설계를 바탕으로 논리적 설계를 해보았다. 즉, 구체화된 업무(=컬럼, 필요한 부분) 중심의 데이터 모델을 만드는 것 = '논리적 설계' 라고 할 수 있다. 이때, 우리가 흔히 알고있는 PK(Primary Key)와 외래키, 속성, 관계 등을 정의 하며, 정규화를 함께 한다. (다들 이론은 알지만, 정규화 부분을 실제로 접목하는 부분은 쉽지 않은 것 같다.) 여기서, 필요한 컬럼을 구체적인 네이밍과, 데이터 타입을 명시한다. 이를 바탕으로 테이블의 Key 도 표기해준다. 필자는 아래와 같이 간단하게 1대 다를 표현해보았다. 전부를 표기한 건 아니지만 대략적으로 기존 테이블에서 다른 테이블에 영향을 미친다. 즉 관계를 알 수 있으며, 구체적인 데이터 타입 까지 명시하였다. 위와 같이 설..

이전에, 요구사항 분석을 했다면 이를 바탕으로 개념적 설계가 필요하다. 크게, 나의 기준에서는 2가지 순서대로 진행하였다. 1. 핵심 Entity 도출 2. ERD 작성 [엔터티 설계 방법] 기획안을 보며 모든 키워드를 뽑아낸다 뽑아낸 키워드를 행위와 데이터로 나눈다. 행위와 데이터는 각각 행위 엔터티, 실체 엔터티로 매핑된다. 다만 모든 행위나 데이터가 DB에 담겨야 하는 것은 아니다. 서버에서 ENUM으로 관리하는 데이터도 있을 수 있다. 2-a. 에서 설계한 엔터티에 관계를 매핑한다. → 관계는 속성! 속성이 필요한 이유는 엔터티 간의 조인을 하기 위해서! 위를 기반으로, 이번 프로젝트에 적용했을 때 이상치 & 결측치 필터링 테이블 (region, area 기준) 1분 데이터 (API 호출 조회) ..