[MySQL] 스터디카페 관리시스템 개발 (2) 시스템 분석

azzurri21·2021년 6월 29일
0

MySQL

목록 보기
2/4

※ 본 시리즈는 정보시스템설계 수업에서 진행된 2인1조 프로젝트의 진행과정을 재구성한 것이며, 작성자는 이벤트 스케쥴러, 날짜 관련 쿼리 구현과 예시 데이터 삽입을 제외한 프로세스 & 데이터 모델링, SQL을 모두 직접 제작했음을 알립니다.

※ 시스템 제작 과정은 Essentials of Systems Analysis and Design 교재에 제시된 SDLC를 참고했습니다.


2. 시스템 분석


2.1 시스템 요구사항 조사

시스템 요구사항을 조사하는 정석적인 방법은 인터뷰, 관찰, 업무 문서를 활용하는 것이다. 하지만 본 프로젝트는 MySQL을 이용한 쿼리의 구현에 초점이 맞춰져 있으므로, 스터디카페 사용자로서 대강 쿼리를 정한 뒤에 데이터 모델링을 염두에 둔 구체적인 요구사항을 작성했다.

Query

  1. 학생ID가 A인 학생의 이름
  2. A학생의 이용권 구매내역 (일시, 이용시간, 저장가능, 가격)
  3. A학생의 대여내역 (자리, 시작일시, 실제마감일시)
  4. A학생이 B자리를 대여할 때 예정마감일시
  5. A학생이 현재 사용 중인 이용권의 잔여이용시간 저장가능 여부
  6. A학생의 잔여이용시간
  7. 대여 가능한 자리의 목록
  8. A학생의 월별 대여시간 합계
  9. 스터디카페 월 매출
  10. 현재시각 모든 학생의 대여 마감 여부

Q1~Q6은 개체의 속성을 정의하기 위해 제작한 쿼리이다.
Q7~Q10은 저장된 데이터에서 사용자인 스터디카페 운영자가 알고 싶은 정보를 추출한다.

[참고] 실제로는 데이터 모델링, 요구사항 조사, 프로세스 모델링이 복합적으로 이루어졌으므로 위 요구사항은 조금 결과론적인 측면이 있다.


2.2 프로세스 모델링

앞서 프로젝트 확인과 선정 단계에서 학생의 스터디카페 이용 절차를 간략히 생각해보았다. 핵심은 프로세스가 이용권 구매를 통한 시간 충전과 자리 대여로 구분된다는 것이다.

이와 같이 관계형 데이터베이스의 구체적인 속성을 고려하지 않고 학생, 이용권, 자리만을 포함한 기초적인 프로세스는 아래와 같다.

프로세스는 학생, 이용권, 자리의 데이터가 수집된 상태를 전제한다.

Process

  • 학생은 시스템에 학생ID를 입력하고 시스템은 해당 학생 ID에 등록된 이름을 출력한다.
  • 시스템은 학생의 잔여이용시간과 판매하는 모든 종류의 이용권을 보여준다.
  • 학생은 이용권을 하나 골라 구매한다.
  • 시스템은 학생의 잔여이용시간에 새로 구매한 이용권의 이용시간만큼을 추가한다.
  • 시스템은 학생의 이용권 구매내역을 출력한다.
  • 시스템은 대여 가능한 자리 목록을 보여준다.
  • 학생은 자리를 하나 골라 대여한다.
  • 학생의 잔여이용시간이 모두 지나거나, 그 전에 학생이 원한다면 대여를 마감한다.
  • 시스템은 이용권의 종류에 따라 학생의 잔여이용시간을 계산하여 갱신한다. (*)
  • 시스템은 학생의 대여내역을 출력한다.

2.3 프로세스 로직

프로세스의 마지막에서 두 번째 단계 이용권 종류에 따라 학생의 잔여이용시간 계산에는 시스템 특유의 비즈니스 룰이 적용된다. 이를 수도코드로 정리해보았다.

Pseudo Code

# 대여 후 학생의 잔여이용시간 계산

if(학생이 현재 사용하는 이용권 is 저장가능) then
    new 잔여이용시간 = old 잔여이용시간 - 대여시간
else
    new 잔여이용시간 = 0

나중에 이를 구현하기 위해 데이터 모델링에서 이용권 개체가 boolen 자료형의 '저장가능' 속성을 보유하도록 설계했다.


2.4 개념적 데이터 모델링

ERD를 작성하는 방법으로 QIM(Query Integration Method)를 사용했다. QIM이란 각 요구사항(query)을 개체(entity)와 관계성(relationship)으로 나타낸 뒤 이를 하나의 ERD로 합치는 것이다.

우선 관여하는 개체에 따라 쿼리를 분류하고 부분 ERD를 그려보았다.

ERD #1 (학생 개체와 속성)

Q1. 학생ID가 A인 학생의 이름
Q6. A학생의 잔여이용시간

ERD #2 (이용권 개체와 구매 관계성, 속성)

Q2. A학생의 이용권 구매내역 (일시, 이용시간, 저장가능, 가격)
Q5. A학생이 현재 사용 중인 이용권의 잔여이용시간 저장가능 여부

ERD #3 (대여 관계성과 속성)

Q3. A학생의 대여내역 (자리, 시작일시, 실제마감일시)
Q4. A학생이 B자리를 대여할 때 예정마감일시

ERD

위 도식들을 통합하고 식별자(identifier)연관개체(associative entity)를 표현하여 그린 최종 ERD는 아래와 같다.

추가 사항:

  • '학생ID'를 학생 개체의 식별자로 등록했다.
  • 자리 인스턴스를 구분하는 식별자인 '자리번호' 속성을 추가했다.
  • 원래 이용권 개체의 식별자는 '이용시간', '저장가능', '가격'의 결합키(composite key)이다. 키를 단순화하기 위해 대리키(surrogate key)인 '이용권번호'를 이용권 개체에 새 속성으로 추가하고 식별자로 지정했다.
  • 같은 학생이 같은 이용권을 구매하는 행위는 발생하는 날짜와 시각에 따라 구별되므로 '일시'를 구매 개체의 식별자(identifier)에 추가했다. 마찬가지로 대여 개체에는 대여의 '시작일시'를 식별자에 추가했다.
  • 다대다 관계성 구매대여를 각각 하나의 연관개체와 두개의 일대다 관계성으로 변환했다.
    (첨언하자면, 임의의 구매 인스턴스 하나는 반드시 학생 인스턴스 하나와 대응하므로 구매는 학생에 대해 mandatory 1 cardinality를 갖는다. 즉, 최소 사상수가 1이다. 학생에 대한 대여의 사상수 또한 이와 같다.)

[참고] 다시 언급하자면, 요구사항을 만들기 전부터 ERD에 대한 구상을 거의 해놓았기 때문에 쿼리에서 ERD로 넘어가는 과정이 조금 부자연스러울 수 있다. 실제로는 데이터 모델링, 요구사항 조사, 프로세스 모델링이 복합적으로 이루어졌다.

profile
파이썬 백엔드 개발자

0개의 댓글