​lesson03) Database Modeling - Data Flow Diagram,논리적 설계

<소프트웨어 설계방법>

8] 데이터베이스 설계 과정

*요구사항 수집 및 분석

- 개념적 설계

- 논리적 설계

- 물리적 설계

(1) 요구사항

- 사용자가 필요로 하는 사항을 일차적으로 수집/조사 

  조사결과를 분석해서 데이터베이스 설계의 제한 조건들이 된다.

- 시스템 사용자의 요구사항 및 기능적 요구사항을 명시 

* 요구사항 수집

- 대상에 대한 일반적인 사항

기존 시스템에 기초 조사

- 설문지 작성 , 담당자 면담 , 업무현장 방문

* 요구사항 분석

- 전체 시스템의 몇개의 기능 단위로 분할 

- 기능을 다시 세분화한 단위로 분할

- 기능과 기능 사이의 관계 명확히 정의

- 전체 시스템 측면에서 기능의 목적과 활동을 재설정(DFD 작성 등도 수행)

(2) 개념적 설계

- 요구 사항분석 결과에 따라

1. 엔티티 추출

2. 애트리뷰트 정의

3. 관계 정의

4. ERD 작성

- 개념 설계는 보통 큰 틀부터 세부적인 애트리뷰트의 분류는 하향식 설계 방식 진행 

(상향식설계 : 구축 대상에서 사용하는 화면 , 양식 ,

전표 등으로부터 모든 데이터 항목을 추출해 낸 후,

비슷한 애트리뷰트들을 그룹화지어 엔티티를 만드는 방식)

- 데이터베이스 관리 시스템의 종류와는 무관

-산출물 : ERD 

(3) 논리적 설계

- 개념 설계에서의 산출물인 ERD를 관계형 스키마와 같은 구현 

 데이터 모델로 변환

- 데이터베이스 관리 시스템 선정

- ERD를 관계형 스키마로 매핑

(4) 물리적 설계

- 데이터베이스 파일에 대한 내부 저장 구조 , 인덱스 접근 경로 등을 명시

- 트랜잭션 고려(질의에 대한 평균 응답시간, 초당 트랜잭션 처리 수/처리량)

- 인덱스 역정규화

* 데이터 흐름도 (DFD; Data Flow Diagram)

- 데이터가 소프트웨어(또는 시스템) 내의 각

  프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림

* DFD의 구성 요소

- 프로세스

- 데이터 흐름

- 데이터 저장소

- 외부 엔티티(객체)

(1) DFD의 프로세스

- 입력되는 데이터를 원하는 데이터로 변환/출력하는 

과정(자체적으로 데이터 생성 불가)

- 원으로 표기

- 프로세스 이름 : 수행하는 업무 또는 수행자

- 프로세스 번호 : 프로세스가 많은 경우 번호를 부여

(2) DFD의 데이터 흐름

- DFD의 구성 요소 간의 인터페이스

(대부분 프로세스들 사이를 연결)

- 화살표로 표기

- 때때로 저장소로부터의 데이터 흐름 표시

- 이름: 선택사항

(3) DFD의 저장소

- 저장된 정보의 집합

 (테이프 , 디스크  ,시스템 상의 자료 저장소 또는  데이터 베이스 의미)

- 두 개의 직선을 평행하게 그리고 직선 사이에 이름을 표기

-데이터 변동X

 (데이터 흐름을 통해 데이터 입출력 표시)

(4) DFD의 외부 엔티티

- 외부 객체

- 프로세스 처리 과정의 데이터 발생의 시작/종료 표시

- 기업의 경우 

내적인 외부 객체 : 관리 , 부서 , 기능 , 시스템 등

외적인 외부 객체 : 고객 , 거래처 , 공공기관 , 외부 시스템등 

- 사각형에 이름을 표기  

* DFD 작성방법

- 배경도를 작성한 후에 하위 레벨이 자료 흐름도를 

세밀하게 작성 최종 완성

(1) 배경도 : 시스템의 최상위 프로세스를 표기한 것. (시스템의 외부에서 바라본 모습)

한 개의 프로세스를 중심으로 외부 객체와의 관계 표시 

==> 시스템 분석 범위 결정

(2) 레벨 0 DFD

: 배경도의 프로세스를 서로 연결되는 몇개의 하위 프로세스로 분할하는 단계

나머지 데이터 흐름은 그대로 유지

(3) 레벨1~3 DFD

: 하위 레벨 DFD

계속 하위 레벨로 세분화하여 자료 저장소를 모두 나타냄

* DFD 작성시 유의사항

- 순서도와 구분

- 입출력 흐름을 명확히 표시 

- 이름들은 쉽고 의미있는 것으로 사용

[9] 논리적 설계

* 요구사항을 분석하고 , 개념설계를 통해 ERD가 작성되면 컴퓨터가 이해할 수 있는 모델링 작업 진행

- 산출물 : 관계형 데이터베이스 스키마 

* 관계(테이블 또는 릴레이션)

- 흔히 부르는 테이블이라는 용어로 사용 

- 관계 행 : 애트리뷰트

- 관계 열 : 튜플(실제 데이터 값)

* 튜플(레코드 또는 행)

- 관계를 구성하는 각각의 행을 의미

- 애트리뷰트의 모임으로 구성

* 애트리뷰트(속성 또는 열)

- 데이터베이스를 구성하는 가장 작은 논리 단위

- 개체의 특성 기술

* 도메인 

- 애트리뷰트가 취할 수 있는 같은 타입의 원자 값들의 집합

- 실제 애트리뷰트 값이 나타날 때, 값의 적합 여부를 검사에도 사용

* 슈퍼키 

- 관계에서 같은 튜플이 발생하지 않는 키를 구성할 때

애트리뷰트의 집합으로 구성하는 것

- 관계에 있는 모든 튜플에 대해서 유일성 만족(최소성은 만족하지 못함)

- 슈퍼키의 최소 형태 : 형태키 

* 후보키

- 관계를 구성하는 애트리뷰트들 중에서 튜플을 

유일하게 식별하려고 사용하는 애트리뷰트들의 부분집합

- 기본키로 사용할 수 있는 애트리뷰트

* 기본키(Primary Key) 

- 후보키 중에서 선택한 주 키

- 널(null)값을 가질 수 없음

- 동일한 값을 중복 사용 불가

* 외래키(Foreign Key)

- 관계를 맺는 두 릴레이션에서 참조하는 릴레이션에 애트리뷰트로 지정되는 키 값

* 참조 무결성 제약조건

- 한 릴레이션에 있는 튜플이 다른 릴레이션에 있는 튜플을 참조하려면 

반드시 참조되는 튜플이 해당 릴레이션 내에 있어야 하는 것

* 키 제약 조건

- 키 애트리뷰트의 값은 릴레이션 내의 각 튜플을 유일하게 식별해야 하는 것 

* 도메인 제약 조건

- 각 애트리뷰트의 값은 반드시 도메인에 속하는 

원자 값이어야 한다

* 엔티티 무결성 제약 조건

-어떠한 기본키 값도 널을 가질 수 없다

* 제약조건의 위배에 따른 처리 

(1) 삽입 연산

- 삽입되는 튜플의 애트리뷰트 값이 도메인이 없는 경우

- 이미 다른 튜플에 있는 기본키 값을 삽입 하는 경우

- 외래키 값이 참조되는 릴레이션의 키 값이 존재하지 않는 경우 

(2) 삭제 연산

- 다른 테이블에서 참조하고 있는 튜플을 삭제 

(3) 수정 연산

 - 기본키나 외래키가 아닌 애트리뷰트의 값 변경은 문제 없으나 , 

그렇지 않은 경우 삽입/삭제 경우의 문제가 모두 나타남 

* ERD와 관계 모델과의 대응 관계

ERD                                     관계 모델

------------------------------------------------------

엔티티타입                            릴레이션

1:1 또는 1:n 관계타입             외래키(또는 관계 릴레이션)

M:N 관계 타입                      릴레이션과 두 외래키

N차 관계 타입                      관계 릴레이션과 N개의 외래키

단순 애트리뷰트                    애트리뷰트

복합 애트리뷰트                    단순 애트리뷰트들의 집합

다치 애트리뷰트                     릴레이션과 외래키

값의 집합                               도메인

키 애트리뷰트                         기본키

* ERwin의 카디널리티

- Zero , one Of More

 1:N 의 경우 - 그에 대응하는 대상이 없을 경우

- One or More

1:N 의 경우 - 반드시 대응하는 대상이 있을 때

- Zero or One 

   1:1 의 경우 - 대응하는 대상이 없을 경우

- Exactly

   대응하는 대상의 정확한 카디널리티 수