DB 설계 - 2.개념적 설계

이전에, 요구사항 분석을 했다면 이를 바탕으로 개념적 설계가 필요하다.

 

크게, 나의 기준에서는 2가지 순서대로 진행하였다.

 

1. 핵심 Entity 도출

2. ERD 작성

 

[엔터티 설계 방법]

1. 기획안을 보며 모든 키워드를 뽑아낸다
2. 뽑아낸 키워드를 행위와 데이터로 나눈다.
   1. 행위와 데이터는 각각 행위 엔터티, 실체 엔터티로 매핑된다.
   2. 다만 모든 행위나 데이터가 DB에 담겨야 하는 것은 아니다. 서버에서 ENUM으로 관리하는 데이터도 있을 수 있다.
3. 2-a. 에서 설계한 엔터티에 관계를 매핑한다. → 관계는 속성! 속성이 필요한 이유는 엔터티 간의 조인을 하기 위해서!

 

위를 기반으로, 이번 프로젝트에 적용했을 때

 

1. 이상치 & 결측치 필터링 테이블 (region, area 기준)
2. 1분 데이터 (API 호출 조회)  테이블 배치 필요 (날짜 기준)
3. 10분 모니터링 대시보드 (테이블) -> 날짜
4. 10분 데이터 테이블 (날짜 기준)
5. 개별 이상치 로그 테이블 (날짜 기준)
6. 이상치 범위 커스텀 테이블 (날짜 기준, 히스토리성)
7. 로그인 및 가입 → admin 계정 관리(CRUD)
8. 냉난방기 테이블 (날짜,region, area  기준) 

 

[ERD] 작성 - 완전히 작성은 아니지만, key 값이 되는 것들 끼리 색상 표현을 해 보았다.

 

모니터링이 주 목적이기 때문에, user에 관한 게시판 화면이 따로 없기에 user 테이블은 외딴섬 같다.

추가적으로  conditioner_1이라는 테이블이 생성되고 있기 때문에, save_dt,region,area와 같은 key 값이 보이지는 않지만, 실제로 끝 부분에 추가되어  insert 테스트 중이다. -> 추후 다시 업로드 예정 

 

실제로, conditioner_1 같은 경우 - 모든 데이터(스마트팜에서 수집하는 데이터)의 컬럼 값이 각 동별로 다르기 때문에, 고민하다가 1테이블에 넣고, 구별자를 넣는 방식으로 진행하였다. 이 부분은 따로 batch pipeline에서 포스팅 하도록 하겠다!

 

처음부터 끝까지 내 손을 통해 백엔드를 구축하는 과정이 쉽지 않지만, 두각을 나타내는 모습에 뿌듯한 마음이 자리잡고 있는 것 같다.