JayK

제 5 절 식별자

1. 식별자(Identifiers) 개념

하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 의미하여 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 한다.

2. 식별자의 특징

3. 식별자 분류 및 표기법

가. 식별자 분류

나. 식별자 표기법

화살표로 표현...........

4. 주식별자 도출기준

해당업무에서 자주 이용되는 속성을 주식별자로 지정

명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않음

-> length가 길어서

복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 함

-> 자식 손자 엔티티 증손자 엔티티까지 복잡한 데이터모델이 구현됨.

5. 식별자관계와 비식별자관계에 따른 식별자

가. 식별자관계와 비식별자 관계의 결정

엔터티 사이 관계유형은 업무특징, 자식엔터티의 주식별자구성, SQL 전략에 의해 결정

나. 식별자관계

자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우

다. ★비식별자관계★

부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용 않고 일반속성으로만 사용하는 경우

라. 식별자 관계로만 설정할 경우의 문제점

PK속성의 수가 데이터 모델의 흐름이 길어질수록 증가 할 수밖에 없다.

마. 비식별자 관계로만 설정할 경우의 문제점

자식엔터티로 상속이 되지 않아 자식엔터티에서 데이터를 처리할 때 쓸데없이 부모엔터티까지 찾아가는 경우 발생

바. 식별자관계와 비식별자관계 모델링

1) 비식별자관계 선택 프로세스

자식엔터티의 독립된 주식별자 구성이 필요한지를 분석

2) 식별자와 비식별자관계 비교

제 4 절 관계(Relationship)

1. 관계의 개념

가. 관계의 정의

엔터티의 인스턴스 사이의 논리적인 연관성으로 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태

나. 관계의 페어링

엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것(페어링)이고 이것의 집합을 관계로 표현

관계 페어링 : 각각의 엔터티의 인스턴스들이 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태

2. 관계의 분류

존재에 의한 관계 : 연관관계는 항상 이용하는 관계로 존재적 관계에 해당

행위에 의한 관계 : 의존관계는 상대방 클래스 행위에 의한 관계가 형성될 때 구분하여 표현

3. 관계의 표기법

관계명(Membership) : 관계의 이름

ex ) 소속된다, 포함한다

관계차수(Cardinality) : ★1:1, 1:M, M:N (p.56)★

관계선택사양(Optionality) : 필수관계, 선택관계 (p.58)

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

가. ★관계 체크사항★

두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?

두 개의 엔터티 사이에 정보의 조합이 발생되는가?

업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가? -> 오답 ★명사★로 나옴

나. 관계 읽기

기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.

대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.

관계선택사양과 관계명을 읽는다.

제 3절 속성(Attribute)

1. 속성 (Attribute)의 개념

업무에서 필요로 한다

의미상 더 이상 분리되지 않는다

엔터티를 설명하고 인스턴스의 구성요소가 된다

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

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

한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.

한 개의 엔터티는 두 개 이상의 속성을 갖는다.

한 개의 속성은 한 개의 속성 값을 갖는다.

3. 속성의 특징

해당 업무에서 필요하고 관리하고자 하는 정보

주식별자에 함수적 종속성을 가져야 함

하나의 속성에는 한 개의 값만 갖는다.

4. 속성의 분류

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

1) 기본속성

업무로부터 추출한 모든 속성 (업무상 코드로 정의한 속성 제외)

2) 설계속성

업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성

3) 파생속성(=추출속성)

다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다.

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

PK(Primary Key)속성 : 엔터티를 식별할 수 있는 속성

FK(Foreign Key)속성 : 다른 엔터티와의 관계에서 포함된 속성

일반 속성 : PK,FK에 포함되지 않은 속성

복합 속성(Composite Attribute) : 여러 세부 속성들로 구성

단순 속성(Simple Attribute) : 더 이상 다른 속성들로 구성될 수 없는 단순한 속성

단일 값(Single Value) : 속성 하나에 한 개의 값을 가진다.

다중 값(Multi Value) : 여러 개의 값을 가진다.

단일 값 속성(Single-Valued Attribute) : 반드시 하나의 값만 존재

다중 값 속성(Multi-Valued Attribute) : 여러 개의 값을 가짐.

=> 다중 값 속성의 경우 하나의 엔터티에 포함 할 수 없으므로 1차 정규화, 별도의 엔터티를 만들어 관계로 연결

5. ★도메인(Domain)★

각 속성이 가질 수 있는 값의 범위 (예시로 범위가 나왔음)

6. 속성의 명명(Naming)

1. 해당업무에서 사용하는 이름을 부여

2. 서술 식 속성명은 사용하지 않음

3. 약어사용은 가급적 제한

4. 전체 데이터모델에서 유일성 확보

제 2절 엔터티(Entity)

1. 엔터티란?

업무에 필요하고 유요한 정보를 저장하고 관리하기 위한 집합적인 것 (Things)

엔터티는 인스턴스의 집합이라고 말할 수 있고, 반대로 인스턴스라는 것은 엔터티의 하나의 값에 해당한다.

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

사각형으로 표현, 엔터티와 엔터티간 ERD를 그린다.

3. ★엔터티의 특징★

반드시 필요하고 관리하고자 하는 정보

유일한 식별자에 의해 식별이 가능

영속적으로 존재하는 인스턴스의 집합 (‘한 개’가 아니라 ‘두 개 이상’)

엔터티는 업무 프로세스에 의해 이용되어야 한다.

엔터티는 반드시 속성이 있어야 한다

다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다

4. 엔터티의 분류

가. 유무형에 따른 분류

유형엔터티 : 물리적인 형태가 있고 안정적이며, 지속적으로 활용되는 엔터티로 업무로부터 엔터티를 구분

개념엔터티 : 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티로 조직

사건엔터티 : 업무 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계 자료에 이용

나. ★발생시점에 따른 분류★

1) 기본/키 엔터티 : 그 업무에 원래 존재하는 정보, 관계에 의해 생성되지 않고 독립적으로 생성,

타 엔터티의 부모 역할

ex) 사원, 부서, 고객, 상품, 자재

2) 중심 엔터티 : 기본 엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할을 함

ex) 계약, 사고, 예금원장, 청구, 주문, 매출

3) 행위 엔터티 : 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터 양이 증가

ex) 주문목록, 사원변경이력

5. 엔터티의 명령

표기법

1. 현업업무에서 사용하는 용어 사용

2. 약어를 사용하지 않음

3. 단수명사를 사용

4. 유일하게 이름을 부여되어야 함

5. 엔터티 생성의미대로 이름 부여

제 1 절 데이터 모델의 이해

1.모델링의 이해

모델링이란?

복잡한 ‘현실세계’를 단순화시켜 표현

모델이란 사물 또는 사건에 관한 양상이나 관점을 연관된 사람이나 그룹을 위하여 명확하게 하는 것

현실 세계의 추상화 된 반영

모델링의 특징 (추상화, 단순화, 명확화)

1) 추상화(모형화,가설적)는 현실세계를 일정한 형식에 맞추어 표현

2) 단순화는 쉽게이해 할 수 있도록 하는 개념

3) 명확화는 누구나 이해하기 쉽게 하기 위해 애매모호함을 제거하고 정확하게 현상을 기술

★모델링의 세 가지 관점★

1) 데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 데이터간의 관계는 무엇인지 모델링하는 방법(what,data)

2) 프로세스 관점 : 무엇을 해야 하는지를 모델링하는 방법 (how,process)

3) 데이터와 프로세스와 상관관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링 하는 방법 (Interaction)

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

데이터 모델링이란?

정보시스템을 구축하기위한 데이터관점의 업무 분석 기법

현실세계의 데이터(what)에 대해 약속된 표기법에 의해 표현하는 과정

데이터베이스를 구축하기 위한 분석/설계의 과정

데이터 모델이 제공하는 기능

시스템을 원하는 모습으로 가시화 하도록 도와준다.

시스템의 구조와 행동을 명세화 할 수 있게 한다.

시스템을 구축하는 구조화된 틀을 제공

시스템을 구축하는 과정에서 결정한 것을 문서화 한다.

다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공

특정목표에 따라 구체화된 상세 수준의 표현방법을 제공

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

중요성

가. 파급효과(Leverage)

성공적으로 수행되고 완료되면 이를 전체를 묶어서 병행테스트, 통합테스트를 수행

=> 데이터 구조의 변경으로 인한 일련의 변경작업은 전체 시스템 구축 프로젝트에서 큰 위험요소

나. 복잡한 정보 요구사항의 간결한 표현(Conciseness)

=>가장 중요한 점은 정보 요구사항이 정확하고 간결하게 표현되어야 한다.

다. 데이터 품질 (Data Quality)

유의성

가) 중복(Duplication)

나) 비유연성(Inflexibility)

-> 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다.

다) 비일관성(Inconsistency)

-> 데이터의 중복이 없더라도 비일관성은 발생

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

가. 개념적 데이터 모델링 (Conceptual Data Modeling)

핵심 엔터티와 그들 간의 관계를 발견하고 표현하기 위해 엔터티-관계 다이어그램(ERD) 생성

데이터 요구를 공식화의 기능

1. 사용자와 시스템 개발자가 데이터 요구 사항을 발견을 지원

2. 현 시스템이 어떻게 변경되어야 하는가를 이해하는데 유용

나. 논리적 데이터 모델링 (Logical Data Modeling)

누가(Who), 어떻게(How: Process), 전산화와는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록

정규화 : 논리 데이터 모델 상세화 과정의 대표적인 활동

논리적 데이터 모델의 상세화 : 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의

다. 물리적 데이터 모델링 (Physical Data Modeling)

데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의

테이블, 칼럼 등으로 표현되는 물리적인 저장구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법

개념적 데이터 모델링 = > 논리적 데이터 모델링 = > 물리적 데이터 모델링

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

Waterfall 기반에서는 데이터 모델링의 위치가 분석과 설계단계로 구분되어 명확하게 정의할 수 있다.

정보공학이나 구조적 방법론에서는 보통 분석 단계에서 업무중심의 논리적인 데이터 모델링을 수행

설계 단계에서 하드웨어와 성능을 고려한 물리적 데이터 모델링 수행

나선형 모델(RUP나 마르미)에서는 분석, 설계단계 양쪽에서 수행 되며 비중은 분석단계에서 논리적인 데이터

모델이 더 많이 수행되는 형태가 된다.

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

가. 데이터독립성의 필요성 ( 데이터 독립성<-> 데이터 종속성 )

지속적으로 증가하는 유지보수 비용을 절감

데이터 복잡도를 낮추며 중복된 데이터를 줄임

끊임없는 요구사항에 대해 화면과 데이터베이스 간 서로 독립성을 유지

-> 데이터 독립성을 확보 시

각 View의 독립성을 유지하고 View에 영향을 주지 않고 변경이 가능

단계별 Schema에 따라 DDL과 DML 다름을 제공

나. 데이터베이스 3단계 구조

외부단계 : 사용자와 가까운 단계로 사용자 개개인이 보는 자료에 대한 관점

개념단계 : 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인

내부적 단계 : 데이터가 물리적으로 ‘저장된 방법’에 대한 스키마 구조

다. 데이터독립성 요소

외부 스키마(External Schema) : View 단계 여러 개의 사용자 관점으로 구성

개개 사용자가 보는 개인적 DB스키마

개념 스키마(Conceptual Schema) : 모든 사용자 관점을 통합한 조직 전체의 DB를 기술

DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마

내부 스키마(Internal Schema) : DB가 물리적으로 저장된 형식

데이터가 실제적으로 저장되는 방법을 표현

라. 두 영역의 데이터독립성

마. 사상(Mapping)

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

가. 데이터 모델링의 세 가지 요소

1) 업무가 관여하는 어떤 것(Things)

2) 어떤 것이 가지는 성격(Attributes)

3) 업무가 관여하는 어떤 것 간의 관계(Relationships)

-> 데이터 모델링을 완성해가는 핵심개념 (Entity,Attribute,Relationship)

나. 단수와 집합(복수)의 명명

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

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

DBA가 데이터 모델링을 전적으로 하는 예는 거의 없다. 업무시스템을 개발하는 응용시스템 개발자가 데이터 모델링도 같이하게 된다.

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

프로젝트에 참여한 모든 IT기술자들은 데이터 모델링에 대해 정확하게 알고 있어야 한다.

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

가. 데이터 모델 표기법

1976년 피터첸(Peter Chen)이 ERD라는 표기법을 만듦.

Entity : 사각형

Relation : 마름모

Attribute : 타원

나. ERD표기법을 이용하여 모델링하는 방법

각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법

데이터 흐름과 프로세스의 연관성의 가장 중요한 표기법이자 산출물

1) ERD 작업순서

1. 엔터티 그림

2. 엔터티를 적절하게 배치

3. 엔터티간 관계를 설정

4. 관계명을 기술

5. 관계의 참여도를 기술

6. 관계의 필수여부를 기술

2) 엔터티 배치

가장 중요한 엔터티를 왼쪽상단에 배치 이것을 중심으로 다른 엔터티를 나열하면서 전개

(사람의 눈이 따라가기에 편한 데이터 모델링 전개)

3) ERD 관계의 연결

초기에는 모둔 기본키 속성이 상속되는 식별자 관계를 설정

중복되는 관계가 발생되지 않도록 설정

Circle 관계도 발생하지 않도록 유의 작성

4) ERD 관계명의 표시

관계이름은 현재형을 사용하고 지나치게 포괄적인 용어 X

5) ERD 관계 관계차수와 선택성 표시

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

가. 완전성(Completeness)

모든 데이터가 데이터 모델에 정의되어 있어야 함 (데이터 모델 검증에서 가장 먼저 확인)

나. 중복배제(Non-Redundancy)

동일한 사실은 반드시 한 번만 기록

다. 업무규칙(Business Rules)

모든 사용자가 해당 규칙에 대해서 동일한 판단을 하고 데이터를 조작함

라. 데이터 재사용(DataReusability)

데이터의 통합성과 독립성에 대해 충분히 고려

마. 의사소통(Communication)

데이터 모델이 진정한 의사소통의 도구로서의 역할

바. 통합성(Integration)

동일한 데이터는 조직의 전체에서 한번만 정의되고 여러 다른 영역에서 참조 활용 하는 것.