2. 목차
Ⅰ.업무분석
1. 프로젝트 개요
2. 시스템 구성도
3. 업무분석 : 업무 기술
4. 업무분석 : 그 밖의 요구사항 분석
Ⅱ. 개념적 설계
1. 엔티티 도출
2. 관계 설정
3. 업무 설정
4. 개념적 ERD
Ⅲ. 논리적 설계
1. 엔티티, 속성 및 식별자 정의
2. 관계 메트릭스
3. 통합 및 검증(모델의 검토)
4. 논리적 ERD
Ⅳ. 물리적 설계
1. 물리적 ERD
3. 1. 휘트니스 센터 강좌관리 시스템
Ⅰ. 업무분석 : 주제선정
● 개요
본 프로젝트는 현실세계에서 이루어지는 업무 중 하나를 선택하여 분석하고 개념적 모델로 표현하고,
이를 바탕으로 데이터베이스를 구축하는 과정을 조원들과 팀을 이루어 실습해보는데 있다.
● 주제선정
본교 헬스장을 모델로 선정하여, 문서로만 이루어지던 특정업무를 선택하여 데이터베이스화 하여
정보시스템을 구축하고, 이를 바탕으로 헬스장에서 이루어지는 특정업무를 효율적으로 관리하겠다.
● 한국성서대 휘트니스 센터 소개
본 프로젝트에 적용될 한국성서대 휘트니스 센터는 교내 밀알관 지하1층에 위치한 곳이다.
휘트니스 센터는 현재 약 100여명의 회원을 보유하고 있으며, 직원은 관리자와 강사를 포함하여 10명 내외이다.
현재 진행중인 스포츠 강좌는 약 10개의 프로그램이 있다.
4. 1. 강좌관리 DB시스템의 필요성
• 데이터모델링을 통해
기존의 강좌관리 업무
시스템보다 시간과
비용을 절약할 수 있
다
Ⅰ. 업무분석 : 주제선정
수강회원조
회
강사정보조
회
강좌관리업무의 예
6. 회원관리
• 강좌조회
- 회원이 수강하고 있는 강좌를 확인
- 각각의 강좌는 강좌코드를 부여
Ⅰ. 업무분석 : 업무기술
특성에 따른 코드부여
강좌코드는 강좌구분문자, 개설순서 순으로 표기
예) CL0001 = CL (강좌) 0001 (1번째로 개설)
7. 회원관리
• 수강회원조회
- 휘트니스 센터 내 강좌를 수강하는 회원만 해당
- 각각의 회원은 수강회원코드를 부여
Ⅰ. 업무분석 : 업무기술
특성에 따른 코드부여
수강회원코드는 회원구분문자, 가입순서 순으로 표기
예) CM0035 = CM (수강회원일련번호) 0035 (35번째로 가입)
8. 강좌관리
• 수강회원 등록
- 강좌를 듣고자 하는 수강생 정보를 등록
- 회원코드와 강좌신청일만을 기록
• 수강회원 조회
- 해당 강좌를 수강하는 수강생 정보를 확인
- 회원명, 생년월일, 성별, 핸드폰번호, 주소 등을
확인
Ⅰ. 업무분석 : 업무기술
9. 강좌관리
• 강사정보 등록
- 강좌를 담당하고 있는 강사에 대한 정보를 확인
- 강사명, 생년월일, 성별, 핸드폰번호, 주소 등을 확인
• 강의실 조회
- 강좌가 이루어지는 강의실 검색
- 강의실 구분을 위해 강의실코드를 부여
Ⅰ. 업무분석 : 업무기술
강의실코드는 강의실구분문자, 호수순서 순으로 표기
예) FR0111 = FR(지상) 0111(111호 강의실)
BR0105 = BR(지하) 0105(105호 강의실)
10. 강사관리
• 강사정보조회
- 강좌를 담당하고 있는 강사에 대한 정보를 검색
- 강좌를 담당하는 강사를 구분하기 위해 강사코드를 부여
- 강사명, 생년월일, 성별, 핸드폰번호, 주소 등을 확인
Ⅰ. 업무분석 : 업무기술
강사코드는 강사구분문자, 입사순서 순으로 표기
예) TM0012 = TM (강사) 0012 (12번째로 입사)
11. 강의실관리
• 강의실명 조회
- 검색하는 강좌에 해당하는 강의실명을 확
인
• 수강회원 조회
- 해당 강의실의 최대 수용인원수를 확인
Ⅰ. 업무분석 : 업무기술
12. 요구사항
• 회원에게 발송할 우편물이 필요하면 부착할 수 있게 주소와 회원명의
라벨이 출력 가능해야 함
• 모든 강좌에 대한 수강인원 수 및 수강회원 정보는 확인 가능해야 함
• 모든 강좌에 대한 강사정보는 확인 가능해야 함
• 현재 진행중인 강좌에 대한 설명이 상세해야 함
• 시스템은 처음 사용사도 쓰기 쉽게 구현하되 직접입력을 최소화
• 현재 진행중인 강좌 검색 시 화면에 한 번에 보여줄 수 있는 최대 갯
수는 10-30개
• 기간이 종료된 강좌 등은 모아두었다 월말에 일괄처리
Ⅰ. 업무분석 : 그 밖의 요구사항 분석
34. 3. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
1. 각 엔티티는 현실세계의 정보를 효과적으로 관리할 수 있는 구조인가?
- 회원 엔티티에서 해당 회원이 수강하는 강좌를 검색함에 있어 발생하는 문제
2. 유사한 내용을 관리하는 엔티티들은 없는가? - 없다
35. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
3. 통합 또는 분리되어야 할 엔티티들은 없는가?
- 강좌 엔티티에서 분리되어야 할 엔티티를 발견
36. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
4. 주식별자는 인스턴스의 유일성을 보장해 주는가?
- 인스턴스의 유일성을 보장해 준다
37. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
4. 주식별자는 인스턴스의 유일성을 보장해 주는가?
- 인스턴스의 유일성을 보장해 준다
5.주식별자에 불필요한 속성이 포함되어 있지는 않은가?
- 포함되어 있지 않음
38. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
6. 주식별자에 속하는 속성이 너무 많지는 않은가?
-class_apply 엔티티 → 복합키(주식별자 2개)를 제외한
모든 엔티티의 주식별자 속성값은 1개입니다.
7. 여러 엔티티 사이에 중복된 속성이 존재하지는 않는가?
-기본키(PK) ↔ 외래키(FK)를 제외한 키(Key)에서는
-중복이 발생하지 않는다.
39. 엔티티 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
8. 날짜를 저장하는 속성이 올바르게 구성되었는가?
9. 속성의 성격상 코드화해야 하는 것은 없는가?
- 이미 코드화가 필요한 속성은 코드화를 완료하였다.
40. 관계의 검토
Ⅲ. 논리적 설계 : 통합 및 검증(모델의 검토)
1. ERD상에서 다른 엔티티와 관계없이 독립적으로 존재하는 엔티티는 없는가?
- 관리자 엔티티가 독립적으로 존재하나 교수님께 조언을 구한 결과
다른 엔티티와의 관계가 필수적으로 필요하진 않다고 판단하였다.
2. 관계를 너무 복잡하게 맺지는 않았는가?
- 그런지 않다. 모든 엔티티는 1:1, 1:N, N:1의 관계로 구성
50. 뷰 정의서
Ⅳ. 물리적 설계 : 뷰 정의서
뷰명 뷰 설명 관련 테이블 SQL
high_class_apply
회원별
수강신청 목록
class_apply
SELECT mem_class_name
From class_apply
WHERE mem_num = 'MM????';
high_class
_member_list
강좌별 수강회원
목록
class_member_li
st
SELECT member_num
From class_member_list
WHERE class_num = 'CL????';
high_teacher 강좌별 강사정보 teacher
SELECT tea_name
FROM teacher
WHERE tea_num = 'TM????';