[SK고용디딤돌] MySQL (3/7) - 3주차

요구사항 명세서를 구조적 문장으로 써야한다.

[ISA 관계]

상위 IS A 하위

상위 엔티티와 하위 엔티티가 1:1 ISA 관계를 가지면 상위 엔티티의 기본키를 하위 릴레이션에 외래키로 추가함으로써 관계 표현

※ 주의

이력은 약엔티티에 가능성이 크다.
강 엔터티가 없으면 약 엔터티가 없다

일반화는 강/약엔터티를 쓰지 않음, 1:1 관계는 1:1을 표시하지 않음 일반화는 다 1:1임

/** 보험회사시스템 **/

1. 고객은 하나 이상의 자동차를 보유 (1:N 관계)

2. 고객은 회사원과 자유업자로 분류 (일반화 / ISA 관계)

3. 자동차마다 사고기록들을 유지한다.

4. 고기록에는 여러 자동차들이 관여할 수 있다. (N:M 관계)

[1:N관계는 중복처리를 못한다. 가해/피해 차량 구분을 못함, 1:N 관계에서는 약티티 일 수 있지만, N:M 관계에서는 강엔터티가 된다.]

5. 고객 : 고객번호(PK), 보험가입일, 집주소

6. 회사원 : 회사원번호(PK), 회사명, 차량용도

7. 자유업자 : 자유업자번호(PK), 업종,주당운행거리

8. 자동차 : 등록번호(PK), 제작년도, 색상정보

9. 사고기록 : 사고번호(PK), 사고장소, 사고발생일시

[보험회사시스템 ERD-1]

[보험회사시스템 ERD-2]

[보험회사시스템 ERD-3] ㅡ 이게 가장 좋은 표현 방식임. 세가지 모두 가능

/** 회사시스템 **/

• 회사는 부서로 조직되어 있다.

• 각 부서는 부서번호, 부서명, 부서장, 부서장 취임일자 정보를 유지한다.

• 한 부서는 여러 곳에 위치할 수 있다.

• 부서는 여러 프로젝트를 통제한다.

• 각 프로젝트는 프로젝트번호, 프로젝트명, 프로젝트 수행장소 정보를 유지

• 한 사원에 대해서는 사번, 성명, 주소, 봉급, 주민번호의 정보를 유지한다.

• 한 사원은 한 부서에 소속되나 여러 프로젝트에서 일할 수 있다.

• 이 때 프로젝트는 같은 부서에 의해 통제되지 않을 수 있다.

• 한 사원이 프로젝트에서 근무하는 시간을 알아야 한다.

• 한 사원에 대해 바로 상위 관리자가 누구인지 알아야 한다.

• 사원은 기술자와 사무원으로 나뉘며 기술자에 대해서는 기술등급을, 사무원에 대해서는 타이핑속도가 중요한 정보이다.

• 의료보험 혜택을 위해 한 사원의 부양 가족에 대한 정보(부양가족이름, 성별, 나이, 본인과의 관계)도 유지되어야 한다.

* ERD 구성

1) 엔티티

- 부서, 프로젝트, 사원, 기술자, 사무원, 부양가족

2) 속성

- 부서번호, 부서명, 부서장, 부서장 취임일자

- 프로젝트번호, 프로젝트명, 프로젝트 수행장소

- 사번, 성명, 주소, 봉급 , 주민번호, 시간

- 상위 관리자

- 기술등급, 타이핑속도

- 부양가족이름, 성별, 나이, 본인과의 관계, 위치(다치속성)

3) 관계

- 통제, 소속, 일, 근무, 나뉨(분류), 유지, 관리

* 구조적 문장

여러 부서에 여러 프로젝트를 통제할 수 있다. (N:M)

한 사원은 한 부서에 소속된다 (1:N)

한 사원은 여러 프로젝트에서 근무할 수 있다  (N:M)

한명의 상위관리자가 여러명을 관리(자기참조)

근무는 시간이 정해져있다(속성)

사원은 기술자와 사무원으로 분류된다.(일반화)

사원은 부양가족[약엔티티]에 대한 정보를 유지한다(1:N)

* 엔티티 & 속성

1) 부서

- 부서번호(PK), 부서명, 부서장, 부서장 취임일자, 위치(다치속성)

2) 프로젝트

- 프로젝트번호(PK), 프로젝트명, 프로젝트 수행장소

3) 사원

- 사번(PK), 성명, 주소, 봉급 , 주민번호, 시간

4) 기술자[일반화1]

- 기술자번호(PK), 기술등급

5) 사무원[일반화2]

- 사무원번호(PK), 타이핑 속도

6) 부양가족

- 부양가족번호(PK), 부양가족이름, 성별, 나이, 본인과의 관계

//

Relationship

1) Identifying : Key - Key

2) Non-identifying : Key - Nonkey

강,약은 같이 박스로 묶은 박스에서 약의 속성을 가르킴

* 3진관계

3진관계가 나타나면 2진관계로 풉니다.

[00레스토랑 모바일 주문/결제시스템]

00레스토랑은 모바일 주문/결제시스템을 개발하고자 합니다.

00 레스토랑은 현재 잠실에 본점, 서울, 분당, 일산에 여러 지점을 운영하고 있습니다

본점은 00레스토랑이 제공하는 모든 메뉴를 선보이고 있으며, 각 지점은 지점의 상황에 맞게 메뉴를 구성해 제공합니다.

고객이 스마트폰으로 해당 지점의 메뉴를 선택하고 수량을 입력해 주문 버튼을 누르면 주문번호가 발행되고 자동으로 주방에 주문 내역이 전달됩니다.

주문내역에는지점명, 주문번호, 주문시각, 주문한 메뉴명과 수량이 표시됩니다.

고객은 주문번호를 클릭하면 주문내역을 확인할 수 있습니다.

식사를 끝내고 나면 결제화면에서 결제내역으로 주문내역과 함께 부가세, 부가세를 포함한 총 금액을 표시하며 결제버튼을 눌러 모바일 결제를 진행할 수 있습니다.

결제가 완료되면 모바일 영수증이 발행되는데 여기에는 결제내역과 함께 해당 지점명, 지점주소, 지점전화번호가 같이 표시됩니다.  

본점과 지점의 주소 및 전화는 다음과 같습니다.

잠실 본점: 서울 송파구 신천동 000

분당 서현역 지점: 경기도 성남시 분당구 000

분당 정자역 지점: 경기도 성남시 분당구 XXX

[00레스토랑 모바일 주문/결제시스템 모델링1]

[00레스토랑 모바일 주문/결제시스템 모델링2]

[레스토랑 FDD]

- 파생속성은 원속성에서 만들어 줄 수 있는 것.

메뉴	메뉴번호(PK)	메뉴명	가격
지점	지점번호(PK)	지점명	지점주소	지점전화번호
결제	결제번호(PK)	주문번호(FK)	결제시각	결제수단	결제금액
주문	주문번호(PK)	주문시각
주문내역	지점별메뉴번호(PK)	주문번호(PK)	주문수량
지점메뉴	지점별메뉴번호(PK)	지점번호(FK)	메뉴번호(FK)

Analyst Designer Developer

[참고]

http://m.blog.naver.com/sillllver/90126393293