데이터 모델링-데이터 모델링

카테고리 없음

데이터 모델링-데이터 모델링

write8770 2024. 8. 11. 19:05

과목5 데이터 모델링

제1장 데이터 모델링 이해

제1절 데이터 모델링 개요

1. 데이타 모델링 정의

가. 데이타 모델링이 제공하는 것

- 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다

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

- 시스템을 구축하는 틀을 제공한다

- 우리가 결정한 것을 문서화 한다

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

- 특정 목표에 따른 다양한 상세 수준을 제공한다

2. 데이타 모델링의 필요성

가. 애플리케이션과 데이터 통합

- 데이타 통합을 기반으로 한 통합은 효과적이고 동시에 저비용으로 통합프로젝트를

안정적으로 수행하면서 성공적으로 완수하기 위한 필요조건

나. 개발자들의 시스템 이해

- 개발자들이 개발한 시스템과 데이터에 대해 좀더 확실하게 이해하기 위해 데이터

모형이 필요

1) 사용자 관점 데이터

- 사용자가 원하는 논리적 개념과 시스템이 물리적 개념을 나타냄

2) 물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질을 정의 할수있다.

3) 애플리케이션간 데이터가 어떻게 사용 되는지 이해하기 쉽니다

- 생명주기 추적정보 제공

다. 데이타 모델링시 주의점

1) 중복 - 동일자료 보관

2) 비유연성 - DATA정의와 사용 프로세스와 분리 프로세스 변화에 관련성이 적음

3) 비일관성 - 임의 DATA 갱신

3.데이타 모델링 단계

가. 개념 데이타 모데링 :

- 주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티를 추출하고

그들간의 관계를 정의함 (ERD이용)

- 사용자와 시스템 사용자가 데이타 요구 사항을 발견하는것 지원

- 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용

나. 논리 데이타 모델링

- 핵심 엔터티와 관계를 바탕으로 상세속성 정의, 식별자 확정 정규화과정을 실행함

- 상세화 : 식별자확정, 정규화, M:M해소, 참조무결성 규칙, 이력관리

다. 물리 데이타 모델링

- DBMS의 특성 및 구현환경등을 감안한 스키마 및 컬럼의 도메인 정의

4.모델링 기본 원칙

*훌륭한 시스템 개발을 위한 단계

- 해결할 문제점들을 선별,결정

- 해결책을 위한 문제점을 상세화

- 시스템 구축

- 실제로 구현

* 논리 데이타 모델링의 접근 방식을 성공적으로 이끄는 기초

가. 커뮤니케이션 원칙

- 요구사항은 모든 사람에게 공표 및 최종 사용자 중심으로 작성

나. 모델링 상세화 원칙

- 정보 구조의 "최소 공통 분모"를 제시

- 데이타는 데이타 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화 되어야 한다.

- 물리 데이타 모델링은 논리데이타 모데링의 변환 과정임

다. 논리적 표현의 원칙

- 모델은 물리적인 제약 조건없이 비즈니스를 그대로 반영해야 한다.

제2절 데이터 모델링 기법 이해

1.데이타 모델 목적

- 설계 단계에서 오류를 최소화 비용과 시간 절감

2.개체-관계 모델 정의

* 사용목적

- 데이타에 대한 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을

하나로 통합할 수 있는 단일화된 설계안을 만듬

- 서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을

정의하기 위해서이다.

3.개체-관계 모델 구성요소 설명

가. 엔티티

- 관심을 갖고 있는 대상

- 동질성

- 독립성

- 집합

- 순수 객체

나. 속성

- 개체 집합의 특성을 설명하는 항목이라고 할 수 있다.

- 식별자 : 개체 집합내에서 각각의 개체를 식별할 수 있도록 하나 또는 그 이상의

속성들로 이루어진 속성 집합

- 단일치 속성(속성값이 오직 하나), 다중치 속성

- 다중치 속성은 새로운 엔터티를 만들며 원래 집합과 M:1관계를 갖는다.

다. 식별자

- 하나 또는 그 이상의 속성으로 구성

- 식별자와 KEY는 일치하지 않을수 있다.

라. 관계

- 엔터티와 엔터티간 연관성을 표현한는 것

- 매핑 카디날리티 : 개체과 연결될때 나타나는 대응 수 (최대, 최소 대응수)

마. 카디날리티

- 데이터베이스가 지켜야 할 제약 조건을 명시함

바. 존재 종속

- 한 엔티티의 존재가 다른 엔티티의 존재에 영향을 받는다면 이를 존재 종속이라 함

사. 서브타입

- 배타적, 포괄적일 수 있다.

3.객체지향 모델링

가. 객체지향 모델링

- 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드로 구성

- 속성 유형과 메소드을 공유하는 객체가 그룹화되어서 객체 클래스가 된다

- 연관/상속을 통해 다는 객체와 연결됨

연관: 객체간의 자연스런 관계

상속: 상위 클레스에서 속성과 메소를 상속받음

* 객체지향 모델링은 모든 비즈니스 규칙이 표현될 수 있는 유일한 환경을 제공한다.

제3절 데이터 모델링 구성요소

1.논리 데이터 모델링 / 물리 데이터 모델링

* 논리에서 물리 데이터 모델링으로 넘어갈 때 유의점

- Super/Sub 관계의 엔터티를 몇 개의 데이블로 만들 것인가?

- 배타적(Arc)관계 엔터티의 외부키를 몇개로 할 것인가?

- 성능향상을 위해 테이블을 추가해야 할 것인가 혹은 통합해야 할 것인가

- 통계 작업을 위해 함께 테이블 같은 임시성 Table을 몇개로 할것이며

유일키는 무엇으로 할 것인가

- 테이블 컬럼을 다른 Table에서 중복할 것인가? 중복한다면 어떤 애플리

케이션이 관련되는가?

- 분산환경에서 데이블 중복할 것인가 중앙에 필요한 Table을 따로 가져갈 것인가?

- 데이터가 분산 환경에서 이동시 문제를 어떻게 해결할 것인가?

4.속성

- 사물의 본질을 이루는 고유한 특정이나 성실

- 6하 원칙으로 도출 (누가, 언제, 어디서, 무엇을 , 어떻게 ,왜)

- 실질적인 정보를 담고 있는 가장 기본적인 단위

제4절 데이터 모델링 표기법

1.바커 표현법

- 속성 : * 반드시 지정 // o : 옵션 # : 실별자

가. 식별자

- 여러개의 속성 중에서 엔터티를 대표할 수 있는 속성

1) 본질 식별자

- 집합의 본질을 명확하게 설명 수 있는 의미상의 주어를 뜻함

2) 후보 식별자

- 각 인스턴트를 유일하게 식별할 수 있는 속성

3) 대체(보조)식별자

- 원래의 식별자를 대신 할 수 있는 또 다른 속성이나 릴레이션쉽

4) 인조 식별자

- 식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정 할 수 없는

여러가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을

속성들로 새롭게됨.

5) 실질식별자

- 인스턴트를 식별하기 위해 공식적으로 부여된 식별자

제2장 개념 데이터 모델링

제1절 개념 데이터 모델링 이해

1. 개점 데이타 모델 정의

- 핵심엔터티(부모가 존재하지 않는 창조된 집합)

2. 개념 데이타 모델 의의

- 대상을 주요 핵심엔터티로 한정한다는 것뿐임

논리적 모델링 기법과 동일하다.

- 하향식으로 모델링을 한다면 개념적 모델링은 개괄적 모델링을 좀더 상세화된

형태로 진화시키거나 중요 엔터티만 선정하여 모델링함으로써 탄생한다

제2절 주제 영역의 정의

1. 주제영역 개념

- 기업이 사용하는 데이터의 최상위 집합

- 계획 수립단계는 하향식 분석을 원칙 검증을 위해서 부분적으로 상향식 분석을

사용한다.

2. 주제 영역 명명

- 실제 업무에서 보편적으로 사용하는 업무 용어를 부여

- 유일한 단수형 명사 사용

- 데이터 그룹을 의미하는 용어 사용(업무 활동을 의미하는 이름은 배제)

3. 주제 영역 활용

가. 목적

- 데이터의 계층적 구조 파악하는데 도움

- 업무기능과 병행하여 분석하는 경우 분석의 최상위 단위 역활을 하여 품질 확보에

기여한다.

- 주제 영역 계층과 기능 계층 간의 대응 관계를 확인한다.

나. 장점

- 데이터 및 업무 활동 모델의 품질보증

- 프로젝트 관리 용이

- 모델 개발 조정 용이 / 요구사항 검증시 사용

- 리포지터리 관리 용이

- 상세 사항의 전개 혹은 축약 기능

4. 주제 영역 도출

- 업무에 사용되는 데이터의 명사형 도출

- 업무 기능의 이름으로부터 도출

- 하향식 접근방법(주제영역에서 출발하여 엔터티 타입으로 전개)

- 상향식 접근방법(엔터티 타입을 그룹핑하여 도출)

- 분석 단계에서의 도출

(아키텍쳐 모델을 정련하는 과정, 데이터 모델 상세화 과정에서 도출)

제3절 후보 엔터티 선정

1. 개념

- 엔터티 선정을 위한 최초 단계.

2. 엔터티 후보 수집

- 시스템도규먼트 : 가장 유용

- 현업 장표 :

- 인터뷰 :도출 단계에서부터 현업과 함께..

- 관련서적

- 프로세스모델링 (데이터스토어/데이타흐름도)

- 타사 또는 유사 시스템의 자료

- 현장조사

2. 엔터티 후보 식별

가.엔터티 후보의 개념 정립

- 단어가 의미하는 진정한 집합이 무엇인지 정의해야 한다

나.관리 대상 판정

- 관리하고자 하는 대상이 맞는가?

다.집합 여부 확인

- 모든 집합이 엔터티는 아님, 모든 엔터티는 집합임.

3. 엔터티 후보 선정 시 유의 사항

- 엔터티 가능성이 있는 것은 일단 검토 대상에 올려 놓을 것

- 후보의 자격이 있다 없다만 확인

- 동의어처럼 보이더라도 함부로 버리지 말것

- 개념이 모호하면 상식화 하여 생각하라

- 프로세스에 연연하지 말라.(DATA 모델은 프로세스가 없다)

- 예외 경우에 너무 직찹하지 말라

- 단어 하나 하나에 집중해서 판단하라

4. 수집된 엔터티 분류

가. 우선 적용 대상 분류

1)KEY 엔터티

- 행위를 발생시키는 주체나 목적어

- 자신의 부모가 없는 엔터티 : 사원, 부서, 고객, 상품, 자재

2)메인 엔터티

- 행위의 집합 중에서 보다 하위의 행위를 발생시키는 주체나 목적어

- 업무의 중심에 해당하는 엔터티 : 보험계약, 사고, 청구, 주문, 매출....

3)액션 엔터티

- 나머지

- 반드시 부모 존재

나. 데이터 영역별 분류

- 우선 적용 대상 분류에서 분류된 핵심 엔터티를 이용하여 분류

- 유사한 엔터티를 함께 모아 검토하는 것

- 하향식 / 상향식 분류가 있음

- 행위의 주체 / 행위 형태로 구분

제4절 핵심 엔터티 정의

1.엔터티

가.엔터티란?

- 우리가 관리하고자 하는 것

- 가로와 세로를 가진 면적(집합)

- 대상 개체들간 동질성이 있는지 확인

- 다른 개체와 확연히 구분되는 독립성

- 순수책체 또는 행위의 집합

2.의미상 주어

- 의미상의 주어를 모델링 입장에서 본다면, 원래의 본질상의 식별자에 해당한다

가. 본질 식별자 정의

- 본질 식별자로 상속 관계를 규명해 올라갔을 때 최상위에 존재하는 것이 바로 KEY엔터티

- 1:M관계에서 1쪽의 엔터티라고 해서 항상 본질 식별자가 되는 것은 아니며

본질 식별자란 만약 그가 없다면 자신이 절대로 태어날 수 없을 때만 해당

3.코드성 키 엔터티 모델링

* 개념적 모델링에서 발현할 것인가 아니면 상세모델링에서 표출할것인가?

가. 이 엔터티가 자식 엔터티를 갖는가?

- 해당 엔터티가 다른 엔터티의 본질 식별자가 되고 있는가를 찾는것

나. 자신만의 다양한 속성을 가질 것인가?

다. 여러 엔터티와 관계를 가지는가?

다양한 종류의 관계를 가지는가?

4.집합의 순수성

가. 집합 순수성의 의미

- 단위 사물을 정의한 개체 이거나 그 해위로 발생한 집합 중 하나 이어야 한다

나. 집합 순순성 적용 예외

1) 릴레이션의 엔터티 (M:M 해소관계에서 생성된 엔터티)

2) 일부집합 엔터티 (금융기관) => 수납기관(행위 + 개체)

3) 배타적 관계 대체

- 배타적 관계의 선분이 지속적으로 늘어 날 경우

각각의 중복성을 감안하고 하나의 엔터티로 생성함.(배송처)

5.집합의 동질성

가.집합 동질성 의미

- 동질성의 한정(범위)를 정하는 것

6.서브타입

가. 서브타입 지정 의의

- 집한내에 들어가는 구체적인 부분집합의 종류를 명시하는 것이다.

나. 서브타입 지정 시 고려 사항

1) 교집합 허용 불가

- 서브타입은 교집합을 허용하지 않음

2) 서브타입의 합은 전체 집합

3) 서브타입의 기준

- 개별 속성을 가진 경우

- 개별 관계를 가진 경우

- 가독성을 증진 시키고자 하는 경우

다. 서브타입의 도출

1) 분류속성 - 분류 속성에 따라 엔티티 정보가 차별화 되는 경우

2) 다수의 선택적 속성 - 다수의 선택적 속성이 존재하는 경우

3) 선택적 관계가 존재하는 경우 -

4) 도출 절차

- 분류 속성 확인

- 분류 속성값에 의한 분류되는 서브타입 파악

- 분류 속성에 따라 필수적/선택적 분할을 정의

- 서부타입별 속성을 할당

- 수터타입의 관계를 해당 서브타입에 정의한다.

라. 서브타입의 활용

1) 업무 규칙을 정확히 이해

- 데이타 모델의 가독성 증가

- 속성의 선택성 제거

- 관계의 선택성 제거

2) 업무 규칙의 명확성과 표현의 복잡성이라는 트레이드 오프 관계가 적절히

조회를 이루어야 한다

7.엔터티 통합과 분할

가. 엔터티 독립성

- 독립성 : 새롭게 정의할 엔터티가 앞서 정의한 어떤 엔터티에도

포함되지 않는 독립적인 집합인가를 확인하는 것

- 독립성은 엔터티 후보의 의미를 명확히 해야 한다

나. 엔터티 분할/통합

- 하나의 집합을 확장하여 통합

- 교차된 부분을 어느 한쪽 집합에 놓고 분리

- 교차된 부분 무시 독립적으로 분리

다. 유연성 향상을 위한 통함

- 통합을 심하게 하면 유연성은 증가되나 의미가 희석됨

- key 엔터티는 통합되어도 하위 엔터티에는 거의 영향을 미치지 않으므로

과감한 통합을 시도하는 것이 바람직하다

제5절 관계 정의

1.관계이해

가. 관계도 집합니다

나. 직접 관계를 관계라고 한다(직접 종속인 것만 관계)

다. 두 엔터티 간에는 하나 이상의 관계가 존재 할 수 있다.

라. 외래키

- 관계는 외래키(Foreign Key)로 구현되어 참조 무결성으로 데이타의

정합성 유지의 역할을 한다

2.관계표현

가. 관계형태

1) 하나 이상

2) 단 하나

나. 선택 사양

1) 일반적인 형태

- M: 항상 1: 옵션널인 경우가 많다

2) 바람직한 형태

- 가능한 직선 관계를 가지도록(특히 자식(Many) 쪽이 실선) 노력

3.관계 형태

가. 1:1 릴에이션쉽

1) 특징

- 현실에서 드문 행태

- 업무의 흐름에 따라 데이터가 설계된 경우 많이 나타남

- 엔터티 수직 분할시에 많이 나타남

2) 필수-선택 형태

3) 필수-필수 형태

- 양쪽 모두다 실선

- 수학적 관계를 풀연 둘은 동일한 집합임

- 데이타 량을 감안하여 수직불할한 경우임

4) 선택 - 선택 형태

- 드물게 발생

나. M:1 릴에이션쉽

1) 특징

- 가장 흔하게 나타남

- 참조하는 쪽은 실선이 되도록 할것

2) Both Side Mandatory

- 잘볼수 없음

3) One Optional

- 가장 흔한 형태

4) Many Optional

- 현실적으로 드문 경우

- 납품건에 대해 한번에 대금 청구를 한경우

5) Both Side Optional

- 현실에서 흔한 형태

- 관계의 선택성이 증가할수록 모델의 모호성도 증가됨

다. M:M 릴에이션쉽

- 양쪽 모두가 점선인 것이 기본형

- 관계 해소되면 새로운 엔터티 발생함

라. 다중관계 처리

- 두 엔터티 사이에 하나 이상의 릴레이션십을 갖고 있는 경우

- 병렬식 : 여러개로 나눠 처리

직렬식 : 하나로 묷어서 처리

1) 병렬식 관계 특징

가) 테이블이 될 때 여러 개의 칼럼이 된다

나) 하나의 로우로 관리 되므로 새로운 TABLE 추가 필요 없음

다) 인덱스 수가 증거되고 SQL 복잡

라) 새로운 관계의 추가, 형태 변화에 취약

마) 관계 내용별로 상세 정보를 관리할 수 없다

- 각 관계에 대한 자식 엔터티를 가질 수 없다

2) 직렬식 관계 특징

가) 관계들을 관리하는 새로운 엔터티가 추가되어함

나) 관계들이 ROW 형태로 나타남

다) 인텍스 수가 감소, SQL단순

라) 새로운 관계의 추가 및 변경에 유연함

마) 관계 내용별로 상세 정보 관리 함 (자식 엔터티 거느릴수 있음)

마. 특수한 형태 관계

1) 순환관계

- 하나의 순환 엔터니는 각 엔터티의 모든 속성을 포함한다

- 각 계층에 있는 속성은 동일하게 하는 것이 좋다

- 순환 모델은 반드시 선택사양(점선)으로 처리

- 순환 모델의 특징은 조직의 변경에 쉽게 대응

2) BOM( Bill of Materials)

- 제조업에서 나타남

- M:M 순환관계

- 상세 모델링 단계에서 새로운 관계 엔터티를 추가하여 두 개의 일대다

1:M 관계로 구성

3) Arc 관계

- 아크내 릴레이션십은 보통 동일

- 아크내 릴레이션십은 항상 필수이거나 선택

- 아크는 반드시 하나의 엔터티에만 속함

- 어떤 엔터티는 다수의 아크를 가질수 있으나 지정된 릴레이션십은

단 하나의 아크에만 사용된다

제3장 논리 데이터 모델링

제1절 논리 데이터 모델링 이해

1. 논리 데이타 모델 정의

- 비즈니스 정보의 구조와 규칙을 명확히 표현하는 것

2. 논리 데이타 모델 목적과 효과

3. 논리 데이타 모델 필수 성공요소

- 업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행

- 절차(Process)보다 데이타에 초점을 둘것

- 데이터 구조와 무결성을 함께 고려

- 개념화, 정규화 기법을 적용하라

- 가능하다면 다이어그렘으로 업무를 표현할 것

- 데이터 모델링을 지원하는 데이터 사전을 구축하라

제2절 속성정의

1.속성 개념

가.속성 정의

- 엔터티에서 관리되는 구체적인 정보 항목으로

더 이상 분리될 수 없는 최소의 데이터 보관단위이다.

나.속성 특징

1) 독자적인 성품을 갖고 있어야 함

2) 속성도 집합이다

3) 릴레이션도 속성이다

- 속성은 전체 엔터티를 통해 반드시 유일해야 함

해당 엔터티 외에 존재하는 속성값들은 사실은 모두 릴레이션십을 의미함.

물리데이터 모델에서 외부키 역할을 하게됨

4) 속성들 간은 서로 독립적이다.(제2정규형)

- 속성간에 종속이 있다면 (제3정규형 위반) 새로운 엔터티로 분리해야 함

2.속성 후보 도출

가.속성후보 수집처

1) 구 시스템 문서자료

2) 현업 장표/보고서

3) 사용자 협의

4) DFD 의 DD

5) 전문서적 및 자료

6) 타 시스템 자료

나. 속성 후보 선정 원칙

1) 원시 속성 후보는 버리지 않는다

2) 소그룹별로 후보군을 만들고 가장 근접한 엔터티에 할당한다

다. 속성의 기본 구성요소

1) 속성명 - 실체명은 사용안함, 단 하나의 실체에만 속해야함

2) 도메인 - 모든 영역에 같은 도메인 사용

3) 선택성 - 해당 속성이 반드시 값을 가져야 하는지

3.속성 검증 및 확정

가. 최소 단위(Atomic Value)까지 분할

나. 하나의 값만 가지는지 검증(제1정규화)

다. 추출 속성인지 확인 - 가공되어 만들어 진 것인지 확인

라. 보다 상세하게 관리할 것인가

4.가공 속성 규칙

- 초기 모델링 : 가공속성 배제할것을 권고

현재 모델링 : 필수 기술 할 것을 권고

- 도출 속성 : 여러 사례에 대해 주제 도출 속성에 대하여 값을 창출키 위해 값에

어떤 추가계산 작업을 수행함으로써 창출되는 속성

- 계산 속성 : 단일 사례로 부터 계산되어진 값

- 도출 속성은 기본 키 역확을 해서는 안됨

- 경영층과 사용자가 원하는 정보

4.속성 정의시 유의사항

가. 의미가 명확한 속성 명칭을 부여한다

나. 유일한 복합명사 사용

다. 단수형으로 속성명을 사용한다

라. 표준 단어 제정(표준용어사전 생성해 두면 유리)

마. 작의적인 전용 금지

* 전용 발생사유

- 모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의했기 때문

- 개발 막바지 또는 이미 사용중인 시스템에 사용자 요구사항 반영으로 인해

새로운 속성의 추가가 필요할때

- ERP 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의한 경우

제3절 엔터티 상세화

1. 식별자(UID, Unique Idntifier)

- 인스턴트의 유일한 구분

- 본질 식별자, 주(실질)식별자, 대체(보조)식별자로 구분할 수 있다.

가. 본질 식별자

- 키 엔터티의 경우 - 식별자 창조

- 행위 엔터티의 경우 - 부모가 누구인지를 확인하는 방식

1)키 엔터티와 본질 식별자

2)절대 종속 / 상대 종속의 의미

- 나를 태어나게하는데 절대적인 역할을 하는것

3)직접 종속 / 간접 종속의 의미

- 1촌 여부

4) 행위 엔터티의 본질 식별자

- 절대종속이면서도 직접종속 인 것

* 본질 식별자를 찾는 가장 확실한 방법 : 6하원칙을 이용

나. 후보 식별자 도출

- 엔터티내에 존재하는 하나 이상의 식별자 중 본질 식별자로 선택되지 않은 식별자들

1) 각 인스턴스르 유일하게 식별할 수 있어야 한다

2) 나머지 속성들을 직접 실별할 수 있어야 한다

3) NULL이 될수 없다.

4) 후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 한다

5) 후보 식별자의 데이터는 자주 변경되지 않는 것이어야 한다

다. 대체(보조) 식별자

- 원래의 식별자를 대신할 수 있는 또 다른 속성이나 릴에이션십.

라. 인조 식별자 지정

- 본질 식별자를 그대로 식별자로 사용할수 없을 경우 전부 혹은 일부를 임의의

값을 가진 속성들로 대체하여 새롭게 구성한 식별자를 말한다

1) 최대한 법용적인 값을 사용한다

2) 유일한 값을 만들기 위한 인조 식별자를 사용한다

3) 하나의 인조 식별자 속성으로 대체할 수 없는 형태를 주의한다.

4) 편의성, 단순성 확보를 위한 인조 식별자를 사용할 수 있다.

5) 의미의 체계화를 위한 인조 식별자를 사용할 수 있다 - 코드화

6) 내부적으로만 사용하는 인조 식별자

마. 식별자 확정

- 자신의 엔터티를 위해 생성하는 것이 아니라 자신을 참조하는 다른 엔터티가 원하는

형태로 결정되어야 하는 것이기 때문에 종합적으로 분석하고 살필것.

1) UID BAR의 두 가지 의미

가) 식별자로서의 역할

나) 정보로서의 역할

- 상대방 식별자를 상속 받아 자신이 보유할 정보가 증가됨

- BAR 있으면 상속과 함께 UID로 추가됨

- 상소받은 UID는 하위 엔터티에 자동으로 외래키역할을 하게됨.

2) UID 상속과 단절의 원리

3) 식별자 확정 절차

- 하향식 방식을 사용

가) 키 엔터티 식별자 확정

- 본질 식별자 확정때 확정을 해도 무방

나) 메인 엔터티 식별자 확정

- 하위 엔터티가 존재하므로 최대한 속성의 갯수를 작게함

이런 이유로 전체를 대신하는 인조 식별자를 만들기도 한다.

2.정규화

가.정규화의 의미

- 변경이상 : 삽입이상, 수정이상, 삭제이상

- 변경이상 -> 데이타 일관성, 무결성에 영향

1) 입력이상

- 불필요한 DATA가 함께 입력

2) 삭제이상

- 원하지 않는 DATA삭제(연대삭제)

3) 갱신이상

- 원하지 않는 정보갱신으로 무결성파괴, 정보의 모순성 발생

나. 정규화의 장점

1) 중복값이 줄어든다

2) Null 값이 줄어든다

3) 복잡한 코드로 데이터 모델을 보완할 필요가 없다

4) 새로운 요구 사항의 발견 과정을 돕는다

5) 업무 규칙의 정밀한 포착을 보증한다

6) 데이터 구조의 안정성을 최대화한다

다. 정규화의 단계

1) 1차 정규화

가) 정의

- 모든 속성은 반드시 하나의 값을 가진다

- 각 속성의 모든 값은 동일한 형식이어야 한다(도메인)

- 각 속성은 유일한 값이어야 한다

- 레코드들은 서로간에 식별 가능해야 한다

나) 정규화 작업

- 어떤 속성이 다수의 값을 가지고 있다면 M:1관계의 새로 엔터티가 추가된다.

2) 2차 정규형

가) 정의

- 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다

- 모든 속성은 기본 key에 종속되어야 한다(물리 데이타 모델링)

나) 정규화 작업

- 어떤 속성 식별바 전체에 종속되어 있지 않으면 잘못된 위치이며 새로운

엔터티 즉, 상위 부모 엔터티를 생성하고 UID BAR를 상속받게 된다.

3) 3차 정규형

가) 정의

- 2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이

존재하면 안된다

나) 정규화 작업

- 부모 엔터티가 생성되고 그 부모 엔터티로부터 UID BAR 없은 관계를

상속받는다

3. M:M 관계 해소

가. M:M 관계의 의미

- 논리 DATA 모데링 관정에서 많이 나타난다.

- Key 엔터티와 Key 엔터티 간에는 대부분 M:M관계임

나. M:M 관계 해소의 의의

- M:M 릴레이션십은 새로운 엔터티를 추가하여 M:1 관계로 변경한다

- 연관실체 엔터티는 M:M 간계 미결시 간과해 버렸을 업무 규칙 또는

업무 논리들을 내포한다

- M:M 관계는 데이터 종속성에 대한 결정을 어렵게하여 모델의 논리적

완성과 부분집합 식별 능력을 제한한다

- M:M 관계 해결시까지 모델은 불안정 상태에 머물것임.

4.참조 무결성 규칙 정의

- 관계 TABLE의 모든 외부 식별자 값은 관련 있는 관계 TABLE의 모든

주 식별자 값이 존재해야 한다

- 실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이타 무결성에

관한 업무 규칙을 내포하고 있다.

- DB 설계 관점이 아닌 사용자 업무 규칙에 따라 적절한 규칙을 선택한다

가. 입력규칙

- Dependent : 대응되는 부모실체에 인스턴트가 존재하는 경우

- Automatic : 자식 실체 입력 항상 허용, 부모의 실체 없으면 자동 생성됨

- Nulliy : 자식 실체 입력 항상 허용, 부모의 실체 없으면 자식 실체의

참조키 NULL 처리

- Default : 자식 실체 입력 항상 허용, 대응되는 부모건이 없는 경우

참조키를 지정된 기본값으로 세팅

- Customized : 특정 조건에 만족하는 경우만 자식 실체 입력

- No Effect : 자식 실체 조건없이 허용

나. 삭제규칙

- Restrict : 대응되는 자식실체 없는 경우만 부모 실체 삭제가능

- Cascade : 부모실체 삭제 항상허용, 대응되는 자식 실체 자동삭제

- Nullify : 부모실체 삭제 항상허용, 대응되는 자식 실체의 참조key를

Null로 세팅

- Default : 부모실체 삭제 항상허용, 대응되는 자식 실체의 참조key를

기본값으로 세팅

- Customized : 특정 조건이 맞는 경우만 부모 실체 인스던트를 삭제

- No Effect : 부모실체 조건없이 무조건 삭제

제4절. 이력 관리 정의

1.이력관리란?

2.이력관리 대상 선정

가.사용자 조사

- 변경 내용을 관리할 필요성

- 시간의 경과에 따라 데이타 변하는가?

- 시간의 경과에 따라 관계 변하는가?

- 과거의 데이터를 조회할 필요가 있는가?

- 과거 버전을 관리할 필요가 있는가?

나.이력 데이타 종류

- 발생이력 데이터 : 데이터가 발생할 때마다 이력 정보 저장 필요

Event 발생시, Daily

- 변경이력 데이터 : 데이터 변경이 될 때마다

- 진행이력 데이터 : 업무 진행에 따른 데이터 이력을 남겨야 하는 경우

ex) 주문 : 구매신청 -> 임금완료 -> 배송 준비..

다. 이력 관리 형태

- 시점이력 : 데이터의 변경이 발생한 시각만을 관리

- 선분이력 : 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리

라. 선분 이력 관리 유형

1) 인스턴스 레벨 이력 관리

- 하나의 인스턴스의 어떤 변경이라도 발생하면 전체 레코드를 새롭게 생성

* 특징

- 한번의 엑세스로 해당 시점 data 모두 발췌

- 로그성 데이터를 저장할 목적인 경우 적당한 방법

- 다른 이력관리 유형에 비해서 저장이 쉽다

- 단점 : 하나 이상의 컬럼에 변경이 발생한 경우 이벤트가 모호해 진다

- 이벤트가 자식 정보를 갖게 된다면 매우 치명적(하위 엔터티 갖을수 없음)

- 저장 공간의 낭비가 심하다

- 변경 여부 확인 위해서는 과거 이력을 Mergeg해서 찾아야 한다

- 특정순간의 스냅샷만 보는 경우 아니면 처리 복잡

- 변화가 빈번히 없다면 고려해볼 만하다

2) 속성 레벨 이력 관리

- 이력을 관리할 대상 속성에서 변화가 생길 때만 이력을 생성함

* 특징

- 실제 변경 데이타 관리가 분명함

- 하나의 이력관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능

- 변화의 가능성적고 관리하는 속성이 많을때 유리

- 특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리

- 여러 속성에 대한 이력 필요시 많은 Merge가 필요함

- 변화가 너무 많은 경우 적용이 곤란

3) 주제 레벨 이력 관리

- 내용이 유사하거나 연동될 확률이 높은 것들 별로 Instance_level 이력을

관리하는 방법

*특징

- 인스턴트레벨과 속성 레벨의 장점만을 이용

- 확장성 확보에 유리

- 변경 부분만 처리 가능

- 다른 엔터티와 통합 이력 관리가 가능

- 속성레벨의 단점해소

- 전체를 참조할때 인스턴스 레벨에 비해 Merge가 발생함

- 부분에 따라 변경 정도의 차이가 심한 경우에 유리

4. 선분 이력 관리용 식별자 확정

가. 선분이력에서 식별자 결정시 고려사항

- 의미적으로 Unique을 점검할 수 있는 조치가 필요함

나.선분이력에서 종료점 처리 시 주의사항

1) 종료점이 미정이므로 Null

- 논리적으로는 타당하지만 비교가 불가능

- 인덱스를 사용하지 못해 수행속도 저하

2)수렴하므로 최대치 부여

- 무한히 계속되는 것으로 간주

- 최대치 부여

- 가능한 TABLE createion시 Default constraints 부여

- 수행속도에 유리

제4장 물리 데이터 모델링

제1절 물리 데이터 모델 정의

- 논리적 DATA 모델을 특정 데이타베이스로 설계함으로써 생성된, 데이터를 저장할 수

있는 물리적인 스키마를 말한다

* 하나의 논리적 데이터 모델을 가지고 서로 다른 물리적 데이터 모델을 설계하는 이유

- 분산 데이터베이스 구축시

- 물리 데이터모델의 비교

- 물리적 환견의 변화로 인해

- 물리적 모델의 형상관리

제2절 물리 요소 조사 및 분석

1. 시스템 구축 관련 명명 규칙

2. 하드웨어 자원

- CPU, MEMORY, DISK, I/O Controller, Network

- 현재 처리 가능한 속도, 집중적인 부하 발생 시간대, 동시 접속 최대 가용 사이트 수

3. 운영체제 및 DBMS 버전 파악

4. DBMS 파라메터 정보 파악

5. DB 운영과 관련된 관리 요소 파악

- 사용자 관리 기법 및 정책

- 백업/복구 기법 및 정책

- 보안 관리 정책

제3절 논리-물리 모델 변환

1.논리데이터 모델 -> 물리 데이터 모델 변환 용어

Entity -> Table

Atrribute -> Column

Primary UID -> Primary Key

Secondary UID -> Unique Key

Relationship -> Foreign Key

Business Constraints -> Check Constraints

2.엔터티-테이블 변환

가. 테이블 설명

나. 서브타입 변환

1) 하나의 테이블로 통합

- 모든 SUB-TYPE의 데이터를 포함

- 주로 SUB-TYPE에 적은 량의 속성이나 관계를 가진 경우에 적용

가) 하나의 TABLE 통합이 유리한 경우

- 데이터 엑서스가 보다 간편

- VIEW를 활용하여 SUB-TYPE만을 엑세스하거나 수정

- 수행 속도가 좋아지는 경우 많다

- SUB-TYPE 구분없는 임의 집합의 가공 용이

- 다수의 SUB-TYPE을 통합한 경우 조인 감소효과가 크다

- 복잡한 처리를 하난의 SQL로 통합하기 유리

나) 불린한 경우

- 특정 SUB-TYPE의 NOT NULL 제한 불가

- 테이블의 컬럼 수가 증가

- 테이블의 블럭 수가 증가

- 처리시마다 SUB-TYPE의 구분이 필요해지는 경우 많다

- 인덱스 크기가 증가

2)여러 개의 TABLE로 분할

- 각각의 SUB-TYPE을 TABLE화 한다

- SUB-TYPE에 많은 양의 속성이나 관계를 가진 경우

가) 유리한점

- 각 SUB-TYPE 속성들의 선택 사양 명확한 경우에 유리

- 처리시마다 SUB-TYPE 유형 구분 필요없음

- 전체 TABLE 스켄시 유리

- 단위 TABLE 크가가 감소

나) 불리한 경우

- SUB-TYPE 구분 없이 데이터 처리하는 경우 UNION이 발생한다

- 처리 속도가 감소하는 경우가 많다

- 트랜잭션 처리시 여러 데이블을 처리하는 경우가 증가

- 복잡한 처리의 SQL 통합이 어려움

- 부분 범위 처리가 불가능해 질수 있다

- 여러 TABLE 합친 뷰는 조회만 가능하다

- UID 유지 관리가 어렵다

3)아크 형태로 적용

- Suber-type과 sub-type을 각가 테이블로 변환한 경우

- Suber-type과 sub-type table간 arc관계 형성

가) 다음의 경우를 만족할때 사용

- 전체 데이터 처리가 빈번하게 발생하는 경우

- sub-type의 처리는 주로 독립적으로 발생할 경우

- 데이블을 통합했을 때 칼럼의 수가 너무 많아지는 경우

- sub-type 의 칼럼 수가 많은 경우

- 트랜잭션이 주로 공통 부분(Super-type)에서 발생한다

- Super-type의 처리 범위가 넓고 빈번하여 단일 테이블

클러스터링을 해야 할때

3.속성-칼럼 변화

가. 일반 속성 변환

- 가능한한 컬럼 명칭은 짧은 것이 좋으며 짧은 명칭은 sql해독 시간을 감소시킴

- 필수 입력 속성은 Nulls/Unique 란에 NN표시

- 실제 TABLE 검증시 표본 DATA 입력

나. Primary UID -> 기본키 변환

1) 변경절차

- PK표시

- PK표시된것은 Nulls/Unique란에 NN,U 표시

- 또 다른 Unique Key 있는 경우는 U2로표기

나. Primary UID(UID Bar 있는경우) -> 기본키 변환

4.관계 변화

가. 1:M

1)1쪽이 필수(Mandatory)관계일 때의 변환 시 주의사항

- 자식 쪽의 ROW가 반드시 하나 이상은 되어야 부모 쪽의 ROW를 생성할수 있다

- 자식 쪽의 ROW를 삭제할 경우에는 전체를 다 삭제할 수는 없고 반드시 하나

이상의 자식 ROW를 남겨두거나 부모, 자식 ROW를 동시에 삭제한다

나. 1:1

1) 주의 사항

- 1:1관계에 의해서 생긴 모든 외래키 부분은 Unique Key 가 필수적이다

- 한쪽이 Optional이고 한쪽이 Mandatory라면 Mandatory쪽의 table에

외래키가 생성된다

- 양쪽다 Mandatory라면 어느쪽에 외래키를 생성할지 결정해야 한다

다. 1:M 순환관계

- 해당 TABLE에 외래키 컬럼 추가

- 외래키는 관계명칭을 사용

- 외래키는 NN이 될수 없다

라. 배타적 관계 변환

1) 외래키 분리 방법

- 각각의 관계 컬럼으로 생성하는 방법

이경우 외래키 제약조건을 생성할수 있다

- 단 가각의 KEY가 옵션널이어야 하고 체크조건이 추가로 들어가야 한다

2) 외래키 결합 방법

- 각각의 관계를 하나의 컬럼을 생성

- 제약조건 줄수 없다

- 관계를 선택적으로 구분할 수 있는 추가 컬럼이 필요함

5.관리상 필요한 칼럼 추가

가. 개념

- 관리상 또는 프로그래밍이 좀더 빠르게 수행되도록 하기위해서 테이블이나

칼럼을 추가할 수 있다.

6.데이타 타입 선택

가. 개념

- 논리적인 데이타 타입(정보 타입)을 물리적인 DBMS별 특성과 성능 등을

고려하여 최적의 데이타 타입을 정의한다

나. 문자타입

1) 세부 문자 타입 선택을 위한 기준

가) 영문만 사용되는가? 한글등이 들어갈경우는 유니코드 처리 테이타 타입 이용

나) 4000자 혹은 8000자 이상의 문자열이 포함된는가? LOGN TEXT이용

다) 입력된 값의 길이가 일정한가? CAHR 비정규 : VARCHAR

다. 숫자타입

1) 선택 기준

- 불린, 정수, 소수, 화패

라. 날짜타입

7.데이타 표준 적용

* 명명 규칙에 의한 표준화 적용

- 업무영역+[주제어 수식어]+ 주제어+[분류어수식어]+분류어+[접미사]

제4절 반정규화

1.데이블 분할

가. 개념

- 데이블을 수평, 수직으로 분할하는 것

나. 수평분할

1)개념

- 레코드를 기준으로 데이블을 분할

EX) 1-3ROW 4-7ROW

2)사용의의

- 레코드 중에서 특정한 덩어리의 범위만을 주로 액세스 하는 경우

- 분할된 각 테이블은 서로다른 디스크에 위치시켜 효율성 극대화

- 범위분할, 해쉬분할, 복합분할 등의 기법

다. 수직분할

1) 개념

- 하나의 데이블에 컬럼의 수가 많아지기 때문에 일어남

- 조회 위주의 칼럼과 갱신 위주의 칼럼으로 나뉘는 경우

- 특별히 자주 조회되는 칼럼이 있는 경우

- 특정 칼럼 크기가 아주 큰 경우

- 특정 칼럼에 보안을 적용해야 하는 경우

2) 갱신 위주의 수직분할

가) 개념

- 테이타를 갱신하는 작업이 일어날 때 업데이트하려는 레코드, 즉 레코드에

잠금을 수행하기 때문

나) DBMS 버전별 적용 검토

- 잠김이 일어나는 경우 변경 레코드외에 다른 컬럼의 조회가 안되는

DBMS의 경우 수직분할에서 사용하는 것이 유리

3) 자주 조회되는 칼럼 분할

가) 개념

- 자주 죄회되는 칼럼만 따로 조회하면 쿼리의 작업 성능을 향상 시킬 수 있다

4) 특정 칼럼의 크기가 아주 큰 겨우 분할

5) 특정 칼럼에 보안을 적용해야 하는 경우의 분할

- 컬럼에 대한 권한 제어을 하고자 할때

2.중복 데이블 생성

가.개념

- 통계정보등을 이용하기 위해

나. 중복 테이블 생성 판단의 근거

- 정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도 증가가 발생하는 경우

- 많은 범위를 자주 처리해야 하는 경우

- 특정 범위의 데이타만 자주 처리하는 경우

- 처리 범위를 줄이지 않고는 수행 속도를 개설할 수 없는 경우

- 요약 자료만 주로 요구되는 경우

- 추가된 데이블의 처리를 위한 오버해드를 고려하여 결정

- 인덱스의 조정이나 부분 범위처리로 유도, 클러스터링을 이용하여 해결할 수

있는지를 철저히 검토 후 결정

다. 중복 테이블의 유형

1) 집계(통계) 테이블

- 로우 수와 활용소를 부석

- 단일 테이블 크러스터링 사용으로 향상 유무 확인

- 클러스터링, 결합 인덱스, 고단위 sql로 해결 가능하지 확인

- 집계 테이블을 다시 집계, 조인 하면 추출할 수 있는지를 검토 추가 테이블 생성을

자제한다

- 추가된 집계 TABLE을 응용프로그램에서 사용할수 있도록 수정필요

- 집계 데이블과 원본 데이블의 일관성 유지

2) 진행 테이블 추가

가) 진행 테이블 추가

- 여러 테이블의 조인이 빈번히 발생하며 처리 범위도 넓은 경우

- M:M 관계가 포함된 처리의 과정을 추적, 관리하는 경우

- 검색조건이 여러 테이블에 걸쳐 다양하게 사용되며 복잡하고 처리량이 많은 경우

나) 진행 테이블 생성시 유의

- 데이터량이 적절하고 활용도가 좋아지도록 기본키를 선정

- 필요에 따라 추출 컬럼 추가 집계 TABLE역할도 수행

- 조인 SQL을 이용하면 굳이 생성하지 않아도 되는 경우 많다

3.중복 칼럼 생성

가. 중복 칼럼 생성 상황

- 빈번하게 조인을 일으키는 칼럼에 대하여

- 조인의 범위가 다량인 경우를 온라인화해야 하는 경우

- 엑세스 조건에 자주 사용되는 칼럼

- 자주 사용되는 엑세스 조건이 다른 데이블에 분산되어 있어 상세조건에도 엑세스

범위를 줄이지 못하는 경우

- 복사된 칼럼은 원본 칼럼과 동일한 도메인 사용

- 접근 경로를 단축위해 부모 컬럼을 자식에게 중복

- 상위 레벨의 테이블에 집계된 칼럼을 추가(M:1)할 수 있다(집계컬럼 추가)

- 하위 레벨의 데이블로 중복 칼럼을 복사(M:1)

- 연산된 결과를 주로 사용하는 경우도 미리 연산을 하여 중복 칼럼을 생성

- 로우로 관리하던 데이터를 칼럼으로 관리하는 경우

- 기본키 컬럼이 길거나 여러개의 칼럼으로 구성되어 있는 경우 인위적인 키본키 추가

나. 중복 칼럼 생성시 유의 사항

- 다중 테이블 클러스터링으로 해결할수 있는지 확인

- SQL GROUP 함수 이용해서 처리 할수 있는지 확인

- 저장 공간의 낭비를 고려

- SUM 기법으로 대체 가능 여부 확인

- 경우에 따라서는 상대 TABLE의 ROWID를 복사하는 경우가 효과적

- 데이터의 일관성 유지

- 중복이 많을경우 오퍼해드에 주의

- 사용자나 프로그램은 원본 칼럼만 수정

- 가능한한 적게 생성