[Java Wep Application] 파이널 프로젝트 Ⅳ. DB 논리/물리 설계

아마 이 또한 회고에 담겠지만, 서버를 구축하고 있는 DB 설계도를 공개하는 바보가 어디 있냐는 말에 따라 틀린 말은 아니지만 공부하는 학생이 만든 프로젝트성 서버인데도..?😭 DB 설계는 항목에 따라 전체 파일 대신 일부 내용만을 포스팅한다.

목차
1. DB 논리 설계
  1.1 테이블 설계서
  1.2 테이블 명세서 작성
  1.3 ERD 작성 (E-R 다이어그램)
2. DB 물리 설계
  2.1 테이블/제약조건 생성
  2.2 더미 데이터 입력
  2.3 뷰 생성

1. DB 논리 설계

정석대로라면 테이블 설계서 작성 → 테이블 명세서 작성 → ERD 작성 의 단계를 거쳐 DB 논리 설계가 이루어진다. 다만 우리는 작업 편의상 ERDCloud 라는 Tool 에서 메모지를 활용하며 ERD 작성을 시작했다. 시간을 되돌리더라도 같은 방법을 택했을 정도로 당시에는 최선의 행동이었지만, 팀 프로젝트 후반부 추후 문서화 작업을 진행하며 별도로 문서를 작성해 두는 것의 중요성을 느끼기도 했다.

1.1 테이블 설계서

『I_Look』 테이블 설계서 미리보기

I_LOOK DB 테이블 설계서.pdf

0.09MB

 

먼저 크게 범례/부모/시터/관리자/일반 돌봄/긴급 돌봄 의 6가지 분류로 영역을 나누었다. 그리고 각 영역에 해당하는 테이블명을 오름차순으로 정렬했다. 테이블에 대한 설명을 함께 작성해 어떤 영역에 어떤 테이블이 존재하는지를 파악하기 쉽게 정리했다.

1.2 테이블 명세서 작성

『I_Look』 테이블 명세서 중 일반 돌봄 예약 신청 테이블(GEN_REQ)

 

팀원 중 안** 학우가 정리에 힘써준 테이블 명세서! ERD 작성 이후 문서화를 뒤늦게 하다보니 ERD와 유사한 모습을 갖추게 되었는데, 사실 ERDCloud 라는 Tool 이 명세 기능을 포함하고 있는건 아닐까?라는 생각도 든다. 테이블 명세서에는 각 테이블명과 테이블 설명, 컬럼명과 컬럼 설명, 컬럼 타입, 컬럼타입 길이(NUMBER나 DATE는 『-』 표시), 기본값, 제약조건(CSTR) 등의 내용을 담았다.

『I_Look』 테이블 명세서 중 영역별 시트 분리

또한 기존에는 엑셀 한 시트에 모든 테이블 명세가 존재했다면, 가독성을 위해 테이블 설계서에서 정리한 각 영역에 따라 (나중에) 시트를 분리했다.

1.3 ERD 작성 (E-R 다이어그램)

『I_Look』 ERD 최종본

 

ERD는 각자 영역을 나누어 작성하려다가 팀 구성원 모두가 각각 전체를 훑어오고 하나로 합치는 방식을 채택했다. 제법 시간이 소요되었지만, 전체 구조를 파악해오니 각자가 이해하고 부분 중 서로 상충되는 부분을 해결하거나 누락한 부분을 채우기에 적합했다. (각자 머릿속에 있는 내용을 도식화해둔 자료를 보여주며 설명할 수 있었기 때문!) 그리고 이때는 몰랐지만 기획과 DB 설계에 오래 머무른 만큼 다른 팀에 비해 개발 단계에서 겪는 시행착오를 줄일 수 있었다.

 

ERDCloud 라는 무료 Tool로 통일하여 작업을 진행했는데, UK, CK 같은 제약조건을 표기하는 데 한계가 있다는 단점이 있지만, 메모지 기능과 함께 팀 작업하기에 훌륭한 작업 도구라고 생각한다.

---

2. DB 물리 설계

Oracle SQL 기반의 DB를 구축하기 위한 Tool은 Oracle SQL Developer를 사용했다. 다른 Tool도 고려해보았지만 훈련과정 중 사용해보았기에 모두에게 익숙한 SQL Developer가 적합하다고 판단했다.

2.1 테이블/제약조건 생성

『I_Look』 DB 물리 설계 중 GEN_REQ 테이블 생성 구문

테이블 생성의 경우 제약조건 생성구문을 별도로 분리하여 작성했다. (단, NN 제약조건의 경우는 테이블 생성구문에 함께 작성해서 제약조건만 조회 시에도 조회가 가능하도록 했다.) 굳이 이렇게 별도로 작성한건, 생성 구문 작성 시 빠뜨리는 제약조건을 쉽게 찾아내기 위해서, 그리고 생성 구문 실행 도중 에러가 발생했을 때 어디서 에러가 발생했는지 빠르게 원인을 찾아내기 위해서였다.

 

그리고 위 이미지에는 포함되지 않았지만 컬럼 타입 및 길이를 변경해야할 일이 생겼을 때는 테이블을 DROP TABLE 하는 것이 아니라 ALTER TABLE 테이블명 MODIFY 컬럼명 컬럼타입; 구문으로 수정했다. 이걸 처음에 몰라서 DROP 과 CREATE를 얼마나 반복했는지 모르겠다.^^

2.2 더미 데이터 입력

『I_Look』 DB 물리 설계 중 GEN_REQ 테이블 더미 데이터 입력 구문

마음이 급급해서 처음에는 각 테이블에 임의의 더미 데이터를 마구 넣었다. 당장 뷰를 생성해야 하는데 아무것도 없으면 뷰 생성 구문을 제대로 작성했는지 확인할 수 없었기 때문이었다. 머지 않아 이게 문제가 되어 결국 새로 더미를 논리에 맞춰 정리했다. ChatGPT 도 명령어를 잘 넣으면 더미 데이터 입력에는 훌륭한 도구가 된다는 걸 깨달았다. 시간이 제법 걸리더라도 더미 데이터도 적당히 구색을 갖추어 깔끔하게, 논리정연하게 넣는 게 정말 중요하다는 걸 배웠다.

2.3 뷰 생성

『I_Look』 DB 물리 설계 중 GEN_REG_POSSIBLE_VIEW 생성 구문

 

VIEW 생성은 말그대로 JOIN의 연속이었다. 특히 우리 팀 메인 기능인 일반 돌봄은 진행 단계가 여럿 있어 테이블 많았고, 이전 단계로 돌아오는 경우도 있었다. 무슨 말인지 예를 들어 설명하자면 아래와 같다.

 

부모 입장에서 일반 돌봄 예약 신청을 진행할 경우,

①시터 등록 근무 등록 건에 신청

②시터 등록 → 타 부모 신청 → 타 부모 취소 → 다시 활성화된 근무 등록 건에 신청

 

이렇게 2가지 케이스가 존재한다. 가장 단순한 구조가 이 정도였다. 또한 VIEW 나 PROCEDURE 의 경우 어떤 게 필요할지 한 번에 파악하는 게 어렵다보니, 가장 기본적인 부분만 작성 후 다음 단계로 넘겨두었다. 즉, 정적 페이지 구성 이후 동적 기능을 구현하며 필요에 따라 하나씩 작성했다.