메뉴 건너뛰기

bysql.net

장_요약

2011.09.02 09:53

balto 조회 수:16556

1장 데이터 모델링의 이해 

1절. 데이터 모델의 이해

1. 모델링의 이해

가. 모델링의 정의
    • 모델: 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형
    • 모델링 : 표기법에 의해 규칙을 가지고 표기하는 것, 모델을 만들어가는 일

나. 모델링의 특징
    • 추상화, 단순화, 명확화

다. 모델링의 세 가지 관점
    • 데이터관점 (what, data)
    • 프로세스 관점 (how, process)
    • 데이터와 프로세스 상관관점 (interaction)

2.데이터 모델의 기본 개념의 이해

가. 모델링의 정의
    • 정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법
    • 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
    • 데이터베이스를 구축하기 위한 분석/설계의 과정

나. 데이터 모델이 제공하는 기능
    • 가시화
    • 명세화
    • 구조화
    • 문서화
    • 다양한 관점 제공
    • 상세 수준 표현 

3. 데이터 모델링의 중요성 및 유의점

가. 파급효과(Leverage)
나. 복잡한 정보 요구사항의 간결한 표현(Conciseness)
다. 데이터 품질 (Data Quality)

※ 중복(Duplication), 비유연성(Inflexibility), 비일관성(Inconsistency) 유의

4. 데이터 모델링의 3단계 진행

가. 개념적 데이터 모델링(Conceptual Data Modeling)
나. 논리적 데이터 모델링(Logical Data Modeling) - 정규화 작업 포함
다. 물리적 데이터 모델링(Physical Data Modeling)

5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

  • 크게 분석단계 & 설계단계 로 구분
  • 목적에 맞게 어떤 생명주기 모델을 사용하는가에 따라 데이터 모델링과 프로세스 모델링을 단계별 진행 또는 동시에 진행 가능

6. 데이터 모델링에서 데이터 독립성의 이해

가. 데이터독립성의 필요성
    • 상호간 영향에서 벗어나 개별 형식이 가지는 고유의 기능을 유지시키며 그 기능을 극대화
    • 유지보수 비용증가
    • 데이터 중복성 증가
    • 데이터 복잡도 증가
    • 요구사항 대응 저하
    • 데이터독립성을 이해하기 위해서는 3단계로 표현된 ANSI 표준 모델 구조, 독립성, 사상(Mapping) 3가지

나. 데이터베이스 3단계 구조
    • 외부단계 - <논리적 데이터 독립성> - 개념적 단계 - <물리적 데이터 독립성> - 내부적 단계
SQL_008.jpg

다. 데이터독립성 요소
    • 외부스키마 : 사용자관점
    • 개념스키마 : 통합관점
    • 내부스키마 : 물리적 저장구조

라. 두 영역의 데이터독립성
    • 논리적인 독립성
    • 물리적인 독립성

마. 사상(Mapping)
    • 논리적 사상 : 외부 화면이나 사용자에게 인터페이스하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결구조
    • 물리적 사상 : 통합된 개념적 스키마 구조와 물리적으로 저장된 구조의 물리적인 테이블스페이스와 연결구조

7. 데이터 모델링의 중요한 세 가지 개념

  • 어떤 것 : 실제 실무 현장에서는 복수/집합개념도 엔터티로 짧게 명명
                       엔터티를 집합개념으로 사용하는 경우, 개별요소에 대해서는 인스턴스/어커런스를 단수의 개념으로 사용
  • 관계(Relationship) : 일반적으로 단수든 복수든 대부분 관계로 표현
  • 성격(Attribute) : 속성과 속성값으로 구분 

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식
나. 데이터 모델링의 이해관계자

9. 데이터 모델의 표기법인 ERD의 이해

가. 데이터 모델 표기법
    • Information Engineering(이하 IE) 표기법
    • 바커 표기법

나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법
    • ERD : 각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법

10. 좋은 데이터 모델의 요소

가. 완전성(Completeness)
나. 중복배제(Non-Redundancy)
다. 업무규칙(Business Rules)
라. 데이터 재사용(Data Reusability)
마. 의사소통(Communication)
바. 통합성(Integration)
 

2절. 엔티티

1. 엔터티의 개념

엔티티 정의들의 공통점은 다음과 같다.

  • 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
  • 엔터티는 업무상 관리가 필요한 관심사에 해당한다.
  • 엔터티는 저장이 되기 위한 어떤 것(Thing)이다.

2. 엔터티와 인스턴스에 대한 내용과 표기법SQL_024.jpg

3. 엔터티의 특징

가. 업무에서 필요로 하는 정보

나. 식별이 가능해야 함

다. 인스턴스의 집합

라. 업무프로세스에 의해 이용

마. 속성을 포함

바. 관계의 존재

4. 엔터티의 분류

가. 유무(有無)형에 따른 분류

일반적으로 엔터티는 유무형에 따라 유형엔터티, 개념엔터티, 사건엔터티로 구분된다.
유형엔터티(Tangible Entity)는 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티로 업무로부터 엔터티를 구분하기가 가장 용이하다. 예를 들면, 사원, 물품, 강사 등이 이에 해당된다. 개념엔터티(Conceptual Entity)는 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티로 조직, 보험상품 등이 이에 해당된다.
사건 엔터티(Event Entity)는 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다. 주문, 청구, 미납 등이 이에 해당된다.

나. 발생시점(發生時點)에 따른 분류

엔터티의 발생시점에 따라 기본/키엔터티(Fundamental Entity, Key Entity), 중심엔터티(Main Entity), 행위엔터티(Active Entity)로 구분할 수 있다.

 

3절. 속성

1. 속성 (Attribute)의 개념

속성의 정의를 정리해 보면 다음과 같다.

  • 업무에서 필요로 한다.
  • 의미상 더 이상 분리되지 않는다.
  • 엔터티를 설명하고 인스턴스의 구성요소가 된다.

의미상 더 이상 분리되지 않는다는 특징을 살펴보면 다음과 같다. 예를 들어 생년월일은 하나로서 의미가 있다. 만약 이것을 생년, 

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

가. 엔터티, 인스턴스, 속성, 속성값의 관계

  • 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
  • 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
  • 한 개의 속성은 한 개의 속성값을 갖는다.
  •  

    나. 속성의 표기법

    속성의 표기법은 엔터티 내에 이름을 포함하여 표현하면 된다.

    SQL_034.jpg

    3. 속성의 특징

    4. 속성의 분류

    가. 속성의 특성에 따른 분류

    속성은 업무분석을 통해 바로 정의한 속성을 기본속성(Basic Attribute), 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성을 설계속성(Designed Attribute), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 파생속성(Derived Attribute)이라고 한다.

     

    나. 엔터티 구성방식에 따른 분류

    엔터티를 식별할 수 있는 속성을 PK(Primary Key)속성, 다른 엔터티와의 관계에서 포함된 속성을 FK(Foreign Key)속성, 엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성을 일반속성이라 한다.

     

    또한 속성은 그 안에 세부 의미를 쪼갤 수 있는지에 따라 단순형 혹은 복합형으로 분류할 수 있다. 예를 들면 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는데 이를 복합 속성(Composite Attribute)이라 한다. 또한 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순한 속성이므로 단순 속성(Simple Attribute)이라 한다.


    일반적으로 속성은 하나의 값을 가지고 있으나, 그 안에 동일한 성질의 여러 개의 값이 나타나는 경우가 있다. 이 때 속성 하나에 한 개의 값을 가지는 경우를 단일값(Single Value), 그리고 여러 개의 값을 가지는 경우를 다중값(Multi Value) 속성이라 한다. 주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 이 속성은 단일값 속성(Single-Valued Attribute)이라 하고, 어떤 사람의 전화번호와 같은 속성은 집, 휴대전화, 회사 전화번호와 같이 여러 개의 값을 가질 수 있다. 자동차의 색상 속성도 차 지붕, 차체, 외부의 색이 다를 수 있다. 이런 속성을 다중값 속성(Multi-Valued Attribute)이라 한다. 다중값 속성의 경우 하나의 엔터티에 포함될 수 없으므로 1차 정규화를 하거나, 아니면 별도의 엔터티를 만들어 관계로 연결해야 한다.

     

    4절. 관계

    1. 관계의 개념

    가. 관계의 정의 
    나. 관계의 패어링

    SQL_039.jpg

    2. 관계의 분류

    관계가 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있는 것은 관계를 연결함에 있어 어떤 목적으로 연결되었느냐에 따라 분류하기 때문이다.

    SQL_040.jpg

    3. 관계의 표기법

    관계에서는 표기법이 상당히 복잡하고 여러 가지 의미를 가지고 있다. 다음 3가지 개념과 함께 표기법을 이해할 필요가 있다.

    • 관계명(Membership) : 관계의 이름
    • 관계차수(Cardinality) : 1:1, 1:M, M:N
    • 관계선택사양(Optionality) : 필수관계, 선택관계
    가. 관계명(Membership)

    관계명은 엔터티가 관계에 참여하는 형태를 지칭한다. 각각의 관계는 두 개의 관계명을 가지고 있다. 또한 각각의 관계명에 의해 두 가지의 관점으로 표현될 수 있다.

    SQL_041.jpg

    나. 관계차수(Degree/Cardinality)

    1) 1:1(ONE TO ONE) 관계를 표시하는 방법

    SQL_042.jpg

    2) 1:M(ONE TO MANY) 관계를 표시하는 방법

    SQL_043.jpg

    3) M:M(MANY TO MANY) 관계를 표시하는 방법

    SQL_044.jpg

    다. 관계선택사양(Optionality)

     이와 같은 것이 데이터 모델 관계에서는 선택참여관계(Optional)가 된다. 참여하는 엔터티가 항상 참여하는지 아니면 참여할 수도 있는지를 나타내는 방법이 필수(Mandatory Membership) 선택참여(Optional Membership)이다.
    SQL_046.jpg

    4. 관계의 정의 및 읽는 방법

    가. 관계 체크사항

    두 개의 엔터티 사이에서 관계를 정의할 때 다음 사항을 체크해 보도록 한다.

    • 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
    • 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
    • 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
    • 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

    나. 관계 읽기

    데이터 모델을 읽는 방법은 먼저 관계에 참여하는 기준 엔터티를 하나 또는 각(Each)으로 읽고 대상 엔터티의 개수(하나, 하나 이상)를 읽고 관계선택사양과 관계명을 읽도록 한다.

    • 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
    • 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
    • 관계선택사양과 관계명을 읽는다.

        (수정) - 교재에는 이렇게 되어 있습니다.

        - 각각의 사원은 한 부서에 항상 속한다.

        - 각 부서에는 여러사원이 때때로 소속된다.

    SQL_047.jpg

    위의 관계를 정의를 한 사항에 대해서 뒷부분만 의문문으로 만들면 바로 관계를 도출하기 위한 질문 문장으로 만들 수 있다. 위의 질문을 업무를 분석하는 자기 스스로에게 질문하거나, 장표나 업무기술서 또는 업무를 잘 알고 있는 업무담당 고객과 대화를 하면서 관계를 완성해 갈 수 있다. 예를 들어, 주문과 제품과 관계를 질문하기 원할 때 “한 주문에 대해서 하나의 제품만을 주문합니까?”라고 할 수도 있고 또는 “한 제품은 하나의 주문에 대해서만 주문을 접수받을 수 있습니까?”라고 질문할 수 있다. 이러한 질문 방법은 엔터티간 관계설정뿐 아니라 업무의 흐름도 분석이 되는 실제 프로젝트에서 효과적인 방법이 된다.