DB설계만 맡아서 하는 직군이 따로 있을 정도로
데이터베이스 설계는 수정할 일이 최대한 없도록 신중하게 해야 한다고 배웠는데,
'나같은 똥덩어리가 설계를 해봤어야 말이지..;-;' 라고 생각할 때 즈음
몇달 전 공부한 데이터베이스개론책에 데이터베이스 설계 파트가 있었다는 것이 떠올랐어요!
사악한 컴퓨터과학 전공자놈들을 따라잡겠다고
컴공과 교과서 중 제일 쉬워보이는 데이터베이스를 가볍게 정독하면서 실습해봤던 게 여기서 빛을 발했습니다.
서적에서 데이터베이스 설계를 진행하는 절차로는
- 요구 사항 분석하기
- 개념적 설계하기 (=E/R 다이어그램 만들기) (중요!)
- 논리적 설계하기 (=릴레이션 스키마 만들기) (중요!)
- 물리적 설계하기
이렇게 진행한다고 기술되어 있어서,
제가 작성한 요구사항 문서를 바탕으로 데이터베이스를 설계하는 과정을 진행하였고 이것이 이 글의 주제에요!
요구 사항 분석하기
데이터베이스개론 서적에 따르면,
'데이터베이스에 대한 사용자들의 요구 사항을 수집하고 분석하여, 개발할 데이터베이스의 용도를 명확히 파악하는 것' 이 요구사항 분석의 핵심 역할이에요!
프로젝트의 컨셉, 기능을 떠올린 문서에서 데이터베이스 설계에 필요한 내용을 추출하여 정리해두면 이후의 설계 단계에서 지표로 활용할 수 있어요.
다행히 이 단계에는 오랜 시간이 걸리지 않았습니다!
제가 작성한 요구사항 문서를 백엔드 파트와 프론트엔드 파트로 나누어 다시 작성했는데,
이 때 백엔드 파트의 문서를 작성할 때 데이터베이스의 '요구사항 분석' 단계까지 미리 고려해서 작성을 해두었어요.
요구사항 분석이 잘못되면 사용자(나)가 원치 않는 쓸모없는 데이터베이스가 생성되어서, 고치거나 새로 생성해야 하는 문제가 발생할 수 있어 신중하게 해야 한대요.
그래서 현재 컨셉 문서에 있는 기능 중 '자기소개 항목'처럼 아직 구현하지 않기로 결정했거나, '프로필 사진'처럼 DB에 어떻게 저장해야 할지 아리송한 항목은 과감히 제거하고 잘 알고 있는 내용만 구현할 수 있도록 데이터베이스 요구사항을 다듬어 완성했습니다!
개념적 설계하기
개념적 설계란 개념적 데이터 모델을 설계하는 단계라는 뜻이에요!
··· 쪼금 더 풀어서 이야기하면,
1단계인 요구사항 분석이 데이터베이스로 구현할 내용을 글로 작성하는 단계였다면,
2단계인 개념적 설계는 데이터베이스로 구현할 개체, 개체에 포함되는 요소, 그리고 개체와 개체를 연결하는 관계에 집중하여 간단한 다이어그램으로 표현하는 것을 의미해요!
간단한 다이어그램으로는 일반적으로 데이터베이스의 종류(DBMS라고 불러요)에 상관없이 표현할 수 있는 E-R 모델을 이용합니다.
책에 자세히 적혀있던 내용을 바탕으로
요구사항 문서를 꼼꼼히 분석하여 '어떤 내용을 개체로 하고 어떤 내용을 요소로 해야 하나?'를 추출해 냈어요.
그리고 위 내용을 바탕으로 E-R 다이어그램을 만들어 저장하였습니다.
개체에 포함된 개체, 개체간 관계가 일대다인지 다대일인지 등 표현하려는 속성에 따라 다이어그램에서 표시하는 방법이 다양하기 때문에
E-R 다이어그램의 문법 문서를 왔다갔다 찾아보면서 최대한 꼼꼼하고 정확히 표현하려 노력했습니다.
이제 이 결과물을 바탕으로 데이터베이스와 유사한 구조를 갖는 논리적 설계를 진행할 수 있어요!
논리적 설계하기
논리적 설계 단계에서는 논리적 데이터 모델을 설계하는 과정이에요!
(고이즈미 신지로 짤)
개념적 설계 단계에서 작성한 E-R 모델이 데이터베이스에 상관없는 모델이라면,
논리적 설계 단계에서는 우리가 사용하려는 데이터베이스에 알맞는 구조로 E-R모델을 재구축(형태에 따라 릴레이션 스키마 또는 테이블 명세서라고 불러요!)해야 해요.
E-R 모델과 관계형 데이터베이스는 구조를 설계하는 방식과 규칙이 많이 다르기 때문에(이를 패러다임 불일치라고 불러요!),
저는 E-R 모델에서 바로 테이블 스키마를 만드는 것은 부적절하다 판단했습니다.
어떤 테이블을 만들고 그 테이블에 어떤 값을 필드로 지정해야 하는 지,
일대다, 일대일, 다대다 등의 연관관계를 구현하려면 어떤 값을 외래키로 지정하고 어떤 값을 또다른 테이블로 분리해야 하는 지(이를 릴레이션 스키마 변환 규칙이라고 불러요!) 세세하게 검토해 그 결과물인 릴레이션 스키마를 먼저 만들었어요.
그 후에 릴레이션 스키마를 바탕으로 테이블 스키마를 만드는 방식으로 논리적 설계를 진행했습니다!
물리적 설계하기
물리적 설계 단계에서는 데이터베이스의 구조나, 프로젝트의 특성을 고려하여
필요한 인덱스 또는 제약사항을 결정하는 단계에요!
당장은 제가 인덱스 개념을 잘 모르기도 하고,
몇 자 이내 또는 어떤 값만 들어가야 한다 등의 제약사항은 어플리케이션 영역에서 검증하고 넘기는 것이 좋겠다 판단하여 특별히 어떤 작업을 하지 않았습니다.
이 영역의 경우 데이터베이스의 주요 구조를 변경하는 것은 아니기 때문에, 프로젝트를 진행하면서 인덱스를 추가해야 하거나 데이터베이스 영역에서의 검증이 필요하다 판단되면 그 때 추가해도 될 거라 생각합니다 :)
물리적 설계 단계에서는 또한 프로젝트가 사용하는 하드웨어나 운영체제 등 사용 환경에 적합하게 데이터베이스를 구성해야 합니다.
저의 프로젝트는 데이터베이스를 사용하기 위해 JPA를 사용하기 때문에,
JPA 환경에서 요구하는 데이터베이스 개체(엔티티라고 불러요!)의 형식에 맞게 코드를 작성하여 물리적 설계를 완료했어요!
이렇게 토이프로젝트에서 사용할 데이터베이스 설계가 완료되었습니다!
토이프로젝트이기 때문에 결국 진행과정에서 데이터베이스 구조가 자주 변경될 확률이 높지만,
그래도 제가 알고 있는 내에서 최대한 꼼꼼하고 체계적인 설계과정을 거쳐
오류가 적고 잦은 수정이 필요없는 탄탄한 데이터베이스를 만들기 위해 노력했어요.
이제 이 데이터베이스를 가지고 서버 애플리케이션을 만들어 봅시다! 고고
