Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 시스템 분석 및 설계, 5판 Essentials of Systems Analysis and Design, Fifth Edition Chapter 7 시스템 요구사항 구조화: 개념적 데이터 모델링 Copyright © 2013 생능출판사 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 7.1

학습 목표 다음과 같은 핵심 용어들을 정의할 수 있다. 개념적 데이터 모델 개체관계성도 개체유형 개체인트턴스 속성 후보키 다중값속성 관계성 차수 사상수 결합개체 7.2

학습 목표 (계속) 정보시스템에 대한 데이터 요구사항들을 결 정하는 데 적합한 질문들을 할 수 있다. 일반적인 비즈니스 상황을 표현하기 위해 개 체관계성도를 그릴 수 있다. 정보시스템에 대한 전반적인 분석과 설계에 있어 개념적 데이터 모델링의 역할을 설명할 수 있다. 일진, 이진, 삼진 관계성들 간의 차이점과 각 각의 예를 제시할 수 있다 관계성과 결합개체 간의 차이를 설명할 수 있고, 데이터 모델에서 결합개체를 적절히 사 용할 수 있다. 7.3

학습 목표 (계속) 데이터 모델링과 프로세스 및 논리 모델링이 각각 정보시스템을 기술하는 상이한 방법이 라는 관점에서, 이것들에 대한 설명을 할 수 있다. 정보시스템 설계 전략을 적어도 3가지 이상 만들어낼 수 있다. 최상의 설계전략을 질적 및 양적 방법 모두 를 이용하여 선정할 수 있다. 7.4

개념적 데이터 모델링 조직의 데이터를 표현 목표는 데이터에 대한 의미와 데이터들 간의 상호관계에 관한 규칙들을 보여주는 것임 목표는 데이터에 대한 의미와 데이터들 간의 상호관계에 관한 규칙들을 보여주는 것임 개체관계성도(Entity-Relationship (E-R) diagrams)는 일반적으 로 데이터들이 어떻게 구조화되는지를 보여주는 데 사용됨 주요 목적은 정확한 개체관계성도를 생성하는 것임 데이터 모델링을 위한 정보들을 수집하기 위해서는 인터뷰, 설문지, 합동애플리케이션설계 회의와 같은 방법들이 사용됨 프로세스 흐름, 의사결정 논리, 데이터 모델 간에는 일관성이 있어야 함 7.5

데이터 모델링의 대상세계와 과정

데이터 베이스 모델링 1. 업무 분석 개발 업무에 대한 정확한 분석 및 사용자들의 요구 사항을 분석하고 어떤 기능을 구현해야 하는 지 분석  2.개념적 데이터베이스 모델링 어떤 정보가 필요하며, 어떤 데이터를 DB에 담아야 하는 지 등을 나타내기 위해 실세계의 정보구조의 모형을 변환하여 일반화 시키는 단계이다 (업무적인 관점에서 접근하고 분석하는 단계이다) ->현재의 업무 프로세스를 일반화 시키는 단계 (네모, 마름모, 동그라미가 얻어짐.) 이러한것 들을 관계형 데이터 베이스 이론에 입각해서 스키마로 변환을 해야함.  3.논리적 데이터 모델링 개념적 설계에서 추출된 실체와 속성들의 관계를 구조적으로 설계하는 단계(스키마의 설계) 로써 정확한 업무 분석을 통한 자료의 흐름을 분석하여 실체와 속성들의 관계를 구조적으로 설계한다. 1) mapping rule 2) 완벽한 정규화 4.물리적 데이터 베이스 모델링 논리적 데이터 모델링에서 정의된 정규화된 모델을 개발 DBMS의 특성 및 효율적 DBMS가 되기 위한 데이터 분산 등을 고려해 데이터 베이스 스키마를 구축하는 단계이다. 1) 개발 DBMS선정 2) 컬럼의 데이터타입과 사이즈 정의 3) 데이터 사용량 분석과 사용자들의 업무 프로세스 분석    (사용자들이 어떤 컬럼을 가지고 정보조회를 하는지...)    (시스템의 효율성을 위해 필요함) 4) 역정규화 5) 인덱스 설정 및 데이터 분산등을 정의 6) 각종 데이터베이스 개체 정의 7) 데이터베이스 생성

개체관계도 (Entity Relationship Diagram: ERD) 하나의 조직 혹은 하나의 업무분야에 있어서 데이터에 대한 자세하고 논리적인 표현 개체(entity) 관계(relationships) 속성(attributes)

개념적 데이터 모델링 수행 절차 기존 시스템에 대한 데이터 모델을 개발하는 것임 새로운 시스템에 대한 모든 요구사항들을 수용하는 개념적 데이터 모델을 개발하는 것임 설계 단계에서, 개념적 데이터 모델은 물리적 설계안 으로 변환됨 프로젝트 리파지토리는 SDLC 상의 모든 설계 단계들 과 데이터 모델링 단계들과 관련됨 7.9

산출물 주요 산출물은 개체관계성도임 개념적 모델링을 통해 다음과 같은 4가지의 ERD가 작성되고 분석될 수 있음 7.10

7.11

산출물 (계속) 두 번째 산출물은 데이터 객체들에 관한 정보들인 데, 이것들은 리파지토리나 프로젝트 사전에 저장 됨 DFD에 포함된 데이터 요소들은 데이터 모델에 나타 나야 하는데, 역으로도 마찬가지임 프로세스 모델의 데이터저장소들   데이터 모델 에서 표현되는 비즈니스 객체들과 DFD의 데이터   ERD의 속성, 관계성과 관련됨 7.13

개념적 데이터 모델링을 위한 정보 수집 2가지 관점 하향식 상향식 비즈니스에 대한 본질적인 이해를 바탕으로 데이터 모델을 도출하는 관점 상향식 구체적인 비즈니스 문서들을 검토하여 데이터 모델을 도출 하는 관점 7.14

개체관계성 모델링 소개 표기법의 3가지 주요 요소 데이터 개체(entity) 관계성(relationship) 속성(attribute) 개체관계성도(Entity-Relationship (E-R) Diagram: ERD) 조직 또는 비즈니스 영역에 관련된 개체들, 관계성 들, 그리고 데이터 요소들에 대한 구체적이고, 논리 적이며, 도식적인 표현방식 7.15

개체관계성 모델링 주요 용어 개체 인스턴스(Entity Instance) 개체(Entity) 개체유형(Entity Type) 조직이 관련 데이터를 관리하고 싶어하는 사람, 장 소, 객체, 이벤트(event), 또는 개념 ERD에서 네모로 표시됨 개체유형(Entity Type) 공통적인 성질 또는 특성을 공유하는 개체들의 집 합 개체 인스턴스(Entity Instance) 개체유형의 단일 발생 사례 7.16

개체 (Entity) 실제적인 혹은 추상적인 것이며, 이것에 대해 데이터(속성의 내용)를 저장 ① 개체에 대해 얼마나 많은 사례들(instances)이 존재하는가? 둘 혹은 그 이 상의 사례들이 존재해야 한다. 하나의 조직에는 보통 두 대 이상의 자동차 가 있다. ② 개체를 설명할 수 있는 얼마나 많은 속성들이 존재하는가? 개체를 설명 할 수 있는 속성이 적어도 둘 이상 있어야 한다. 자동차를 설명할 수 있는 속성으로는 자동차 번호, 자동차 종류, 자동차 구입날짜, 자동차 소유주 등이 있다. 개체유형(entity type): 공통의 속성 혹은 특성을 가지는 개체사례(entity instance)들의 집합 개체사례(entity instance): 개체유형의 하나의 경우(a single occurrence) 사람(종업원, 환자, 학생, 고객 등) 지역(지점, 나라, 시, 판매지역, 등) 개념(계정, 과목, 부서 등) 물체(도서, 부품, 디스크 등) 사건(예금, 학기, 시험, 판매, 등록 등)

개체는 사각형의 기호로 개체관계도에서 표시되며 명 사형으로 이름을 붙임

개체관계성 모델링 (계속) 주요 용어 속성(Attribute) 조직에서 관심 있어 하는 개체의 성질 또는 특성 모든 혹은 대부분의 개체의 사례들에 있어서 공통적인 특성 학  생: 학생 번호, 학생 이름, 학생 주소, 학생 전화번호 자동차: 자동차 번호, 자동차 색깔, 자동차 내용연수, 자동차 소유 주 종업원: 종업원 번호, 종업원 이름, 주소, 전화번호 부양가족: 종업원 번호, 부양가족 이름, 관계 타원형으로 표시되어 있으며 명사형으로 이름을 붙임 7.19

개체관계성 모델링 (계속) 주요 용어 후보키(Candidate Keys)와 식별자(Identifiers) 모든 개체유형은 적어도 인스턴스들을 고유하게 구별할 수 있는 속 성을 적어도 하나 이상 가져야 함 후보키 하나의 개체유형에 대한 각각의 인스턴스들을 고유하게 구별할 수 있도록 해주는 하나의 속성 또는 몇 가지 속성들의 조합 주요키: 후보 키들 중에서 식별자(identifier)로 선택된 키가 주요키(primary key), 값 이 변경되지 않아야 하며 Null값이 될 수 없음 외래키(Foreign Key): 주요키이나 외부 개체에서 가져온 키로 다른 개체와의 연결 고리 과정 프로그램코드(주키) 프로그램 이름 학위유형 학과번호(외래키) 학과 학과번호(주키) 학과이름 7.20

7.21

개체관계성 모델링 (계속) 주요 용어 식별자 하나의 개체유형의 인스턴스들을 고유하게 구분 하는 데 사용하기 위해 사용되는 후보키 중 하나 식별자 선정 규칙 개체유형의 각 인스턴스들이 시간에 따라 값이 변하지 않는 후보키를 골라라 공값(null value)이 될 가능성이 없는 후보키를 골라라 지능키(intelligent keys) 사용을 피하라 부품의 개체- **&& 첫 두자리는 재고위치 기다란 복합키(composite keys) 대신에 단일 속성으로 된 대리키(surrogate keys)의 사용을 고려하라 직원 개체 – 이름+주소보다는 사번이 적절 7.22

표시 함 표시 함 표시 개체관계성 모델링 (계속) 주요 용어 다중값속성(Multivalued Attribute) 각각의 개체인스턴스에 대해 하나 이상의 값을 가 질 수 있는 속성 ERD에서는 다음과 같은 2가지 방식으로 표현될 수 있음 집합기호( { } ) 안에 표시함 약개체(weak entity) 표시 함 직원 사번 {부양가족_이름. 부양가족_나이. 부양가족_관계.} 표시 함 직원 사번 부양가족 부양가족_이름. 부양가족_나이. 부양가족_관계. 표시 7.23

개체관계성 모델링 (계속) 주요 용어 관계성(Relationship) 조직에서 관심대상이 되는 하나 이상의 개체유형들 간 의 연관관계 연관관계는 대개 개체인스턴스들 간에 발생하는 사건 또는 자연스러운 관계를 의미함 관계성은 항상 동사형의 이름을 가짐 7.24

개념적 데이터 모델링과 E-R 모델 결과적으로는 목적 가능한 한 데이터의 의미를 많이 포착하는 것 설계 및 그 이후 유지보수 단계까지를 더 용이하게 해 줄 수 있는 더 좋은 설계 안에 이르게 하는 것이다 7.25

관계성의 차수 차수(Degree) 3가지 경우: 하나의 관계성에 연결된 개체유형들의 개수 일원관계(Unary) 1개의 개체유형의 인스턴스들 간의 관계성 이원관계(Binary) 2개의 개체유형들 간의 관계성 삼원관계(Ternary) 3개의 개체유형들 간의 동시적인 관계성 3개의 이진관계성과는 같지 않음 7.26

7.27

사상수(Cardinality) 어느 한 개체의 인스턴스가 관련될 수 있거나 관련되어야 하는 다 른 개체의 인스턴스의 개수 최소 사상수 개체 A의 인스턴스 각각에 연관될 수 있는 개체 B의 인스턴스들의 최 소 수 최대 사상수 개체 A의 인스턴스 각각에 연관될 수 있는 개체 B의 인스턴스들의 최 대 수 7.28

ⓐ 1:1 예) 하나의 주문은 반드시 한 명의 고객에 의해 행해진다. ⓑ 1:n 예) 주문은 적어도 하나 이상의 품목을 포함하고 있다.  ⓐ와 ⓑ의 경우 반드시 최소 하나 이상의 사례가 관여해야 하므로 이러한 경우가 강제적인 관계를 의미함 ⓒ 0:1 예) 주차장을 할당 받지 못한 사람도 있고, 할당 받았다면 하나의 주 차장소만 있다. ⓓ 0:n (0을 의미하는 원표시가 생략된 형태) 예) 한 고객이 주문을 한번도 하지 않은 경우도 있고, 한 고객이 여러 번 주문을 한 경우도 있다.  ⓒ와 ⓓ의 최소 사상수가 0일 수도 있으므로 이러한 경우를 선택적 관계

결합개체(Associative Entity) 하나 이상의 개체유형들에 대해 인스턴스들을 서로 연관시키면 서 이러한 관계성에 대해 고유한 속성들을 포함하는 개체유형 속성은 개체만 가질 수 있게 되는데 관계에서 속성이 발생하게 되어 관계가 개체가 되는 형태 m:n  1:m, n:1 7.30

7.31

PVF WebStore: 개념적 데이터 모델링 인터넷 애플리케이션에 대한 개념적 데이터 모델링은 다른 애플리케이션 유형들에 대한 데이터 분석 과정과 차이가 없음 Pine Valley Furniture WebStore 정의된 4가지의 개체유형들 고객 재고 주문 장바구니 7.32

7.33

최상의 설계전략 대안 선정하기 2가지의 기본 단계들 설계전략 구축 과정 포괄적인 범위에서 설계전략 대안들을 마련함 원하는 정보시스템을 만들어 낼 수 있는 가능성이 가장 높 은 설계 전략을 선택함 설계전략 구축 과정 요구사항들을 여러 가지의 시스템 역량 수준들로 나눔 사용자가 수용 할 수 있는 최소 수준 회사가 지원 가능한 다양한 수 준까지 여러 가지의 시스템 역량 수준을 제공하는 데 필요한 구축 환경 요소들을 열거함 하드웨어, 네트워크플랫폼, 시스템소프트웨어, 기술적제약 이러한 구축 환경 요소들을 조달하거나 획득할 수 있는 다 양한 방법들을 제시함 7.34

최상의 설계전략 대안 선정하기 (계속) 산출물 새로운 시스템 구축을 위한 최소한 3가지의 상당 히 다른 설계 전략들 가장 바람직한 정보시스템을 구축할 가능성이 높 은 것으로 판단되는 하나의 설계 전략 7.35

설계전략 대안 생성하기 가장 바람직한 3가지 대안들 하급 상급 중급 기존 시스템과의 차이를 최소로 하면서 사용자들이 요구 하는 수준의 기능들을 모두 제공 상급 주어진 문제를 단순히 해결하는 수준을 넘어 사용자들이 필요로 할 가능성이 있는 추가적인 기능들을 제공 중급 상급 대안의 특성과 하급 대안의 검소함이 절충된 대안 7.36

Hoosier Burger의 새로운 재고관리시스템 [그림 7-18]은 3가지 대안들을 보여줌 대안 A는 하급 제안 대안 C는 상급 제안 대안 B는 중급 제안 7.37

Hoosier Burger의 새로운 재고관리시스템 (계속) 최상의 대안 선택하기 이 3가지 대안들을 비교하기 위해 가중치 접근방 법이 사용될 수 있음 [그림 7-19]는 Hoosier Burger에 대한 가중치 접 근방법을 보여주고 있음 테이블의 왼쪽 부분은 결정 기준들을 보여줌 제약조건들과 요구사항들 가중치는 분석 팀, 사용자, 관리자 간의 논의를 통해 도출됨 각각의 요구사항과 제약조건에 대해 등급을 매김 1점 등급은 대안이 요구사항을 잘 충족시키지 못하거나 제약조 건을 위한하는 경우에 부여됨 5점 등급은 대안이 요구사항을 충족시키거나 기준 이상으로 충 족시키는 경우 그리고 제약조건을 잘 준수하는 경우에 부여됨 7.38

설계전략 대안들의 범주 정하기 최소한의 요구사항들 필수적인 특성들 versus 바람직한 특성들 특성들의 형태 시스템 보관 데이터 – 다수의 배송주소 등록 및 관리 시스템 결과물 – 인쇄된 보고서, 온라인화면, 거래처리문서(예) 매출요약 그래프, 급여지 급명세서, 소득금액증명원, 재직증명서…) 시스템 산출물에서 보여줄 정보를 처리 분석 – 할부청구서 처리 절차, 매출예측모듈 접근성, 응답 시간, 시스템 기능의 처리 시간에 대한 사용자 의 기대 – 온라인 재고파일에 대한 실시간 갱신 7.39

설계전략 대안들의 범주 정하기 (계속) 시스템 개발에 따른 제약조건 시간 재원 – 사용 가능한 재무적, 인적자원 변경이 불가능한 기존 시스템의 요소들 법률적 제약 및 계약관계 제약 사용 시스템의 변경금지, 사용자 수 제한 문제의 중요성 또는 역학관계 데이터의 중요성에 따라 외주 불가, 구입이 불가능한 경우 7.40

Hoosier Burger의 새로운 재고관리시스템 기존 체계를 대체 [그림 7-15]는 시스템 요구사항들과 제약조건들에 대한 우선순위를 보여줌 7.41

7.42

Hoosier Burger의 새로운 재고관리시스템 (계속) [그림 7-16]은 기존 체계에서 이루어지는 작업 단 계들을 보여줌 대안들을 제시할 때, 요구사항들과 제약조건들이 고려되어야 함 7.43

7.44

Hoosier Burger의 새로운 재고관리시스템 (계속) [그림 7-18]은 3가지 대안들을 보여줌 대안 A는 하급 제안 대안 C는 상급 제안 대안 B는 중급 제안 7.45

Hoosier Burger의 새로운 재고관리시스템 (계속) 최상의 대안 선택하기 이 3가지 대안들을 비교하기 위해 가중치 접근방 법이 사용될 수 있음 [그림 7-19]는 Hoosier Burger에 대한 가중치 접 근방법을 보여주고 있음 테이블의 왼쪽 부분은 결정 기준들을 보여줌 제약조건들과 요구사항들 가중치는 분석 팀, 사용자, 관리자 간의 논의를 통해 도출됨 각각의 요구사항과 제약조건에 대해 등급을 매김 1점 등급은 대안이 요구사항을 잘 충족시키지 못하거나 제약조 건을 위한하는 경우에 부여됨 5점 등급은 대안이 요구사항을 충족시키거나 기준 이상으로 충 족시키는 경우 그리고 제약조건을 잘 준수하는 경우에 부여됨 7.46

7.47

Hoosier Burger의 새로운 재고관리시스템 (계속) 최상의 대안 선택하기 (계속) 가중치를 반영했을 때, 대안 C가 최상의 대안이 됨 7.48

요약 개념적 데이터 모델링 과정 개체관계성 모델링 관계성의 차수 산출물 정보 수집 개체 속성 후보키와 식별자 다중값속성 7.49

요약 (계속) 사상수 결합개체 개념적 데이터 모델링과 인터넷 애플레케이션 개 발 설계전략 대안 생성 7.50

ERD Drawing Practice 요구 조건 명세 - 정보처리 강의 사이트의 주된 구성원은 수강생과 과목이다. - 수강생은 고유의 아이디가 부여되며, 추가로 주민등록번호, 이름 정보를 가진다. - 강사는 고유의 강사번호가 부여되며, 추가로 주민등록번호, 이름 정보를 가진다. - 과목은 고유의 과목번호가 부여되며, 추가로 과목명, 과목내 용 정보를 가진다. - 한 명의 강사는 하나 이상의 과목을 강의할 수 있다. - 한 명의 수강생은 한 과목 이상을 수강하거나 하지 않을 수 있다. - 각 수강생이 수강한 과목에 대해서 성적이 부여된다.

ERD Drawing Practice 1 요구 조건 명세 정보처리 강의 사이트의 주된 구성원은 수강생과 과목 이다. 수강생은 고유의 아이디가 부여되며, 추가로 주민등록 번호, 이름 정보를 가진다.

ERD Drawing Practice 1 요구 조건 명세 강사는 고유의 강사번호가 부여되며, 추가로 주민등록 번호, 이름 정보를 가진다.

ERD Drawing Practice 1 요구 조건 명세 과목은 고유의 과목번호가 부여되며, 추가로 과목명, 과 목내용 정보를 가진다.

ERD Drawing Practice 1 요구 조건 명세 - 한 명의 강사는 하나 이상의 과목을 강의할 수 있다.

ERD Drawing Practice 1 요구 조건 명세 - 한 명의 수강생은 한 과목 이상을 수강하거나 하지 않 을 수 있다. - 각 수강생이 수강한 과목에 대해서 성적이 부여된다.

ERD Drawing Practice 2 Example 1 Business rules (i.e., relationships) a professor (ID, LNAME, LNAME) teaches zero, one or many classes and a class(ID, NAME, Course ID) is taught by one professor a course(ID, NAME) may generate zero, one or many classes and a class comes from one course a class is held in one room but a room(ID, Location, Capacity) has many classes Students (ID, FNAME, LNAME, STREET, CITY, ZIP) take one or many classes and A class have zero or many students.

ERD Drawing Practice 2 Example 1 A professor (ID, LNAME, LNAME) teaches zero, one or many classes and a class(ID, NAME, Course ID) is taught by one professor  

ERD Drawing Practice 2 Example 1 A professor teaches zero, one or many classes and a class is taught by one professor A course(ID, NAME) may generate zero, one or many classes and a class comes from one course  

ERD Drawing Practice 2 Example 1 A professor teaches zero, one or many classes and a class is taught by one professor A course may generate zero, one or many classes and a class comes from one course A class is held in one room but a room(ID, Location, Capacity) has many classes

ERD Drawing Practice 2 Example 1 Students (ID, FNAME, LNAME, STREET, CITY, ZIP) take one or many classes and A class have zero or many students.

ERD Drawing Practice 2 Example 1 The many-to-many relationship is not resolved, therefore the solution is incomplete. In the final solution the many-to-many must always be resolved.

ERD Drawing Practice 2

Assignment: ERD Drawing an invoice is written by one salesman but a salesman writes many invoices a vendor sells many products but a product is bought from one vendor an invoice has one or many products and a product is found on zero, one or many invoices